From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG15 beta1 sort performance regression due to Generation context change |
Date: | 2022-06-02 21:37:02 |
Message-ID: | CAApHDvq8MoEMxHN+f=RcCfwCfr30An1w3uOKruUnnPLVRR3c_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2 Jun 2022 at 20:20, John Naylor <john(dot)naylor(at)enterprisedb(dot)com> wrote:
> If anything, changing work_mem is an
> easy to understand (although sometimes not practical) workaround.
I had a quick look at that for the problem case and we're very close
in terms of work_mem size to better performance. A work_mem of just
64.3MB brings the performance back to better than PG14.
postgres=# set work_mem = '64.2MB';
postgres=# \i bench.sql
c1 | c2 | c3 | c4 | c5 | c6
----+----+----+----+----+----
(0 rows)
Time: 28949.942 ms (00:28.950)
postgres=# set work_mem = '64.3MB';
postgres=# \i bench.sql
c1 | c2 | c3 | c4 | c5 | c6
----+----+----+----+----+----
(0 rows)
Time: 19759.552 ms (00:19.760)
David
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2022-06-02 21:46:25 | Re: Proposal: adding a better description in psql command about large objects |
Previous Message | Andrew Dunstan | 2022-06-02 21:17:34 | Re: pg_upgrade test writes to source directory |