From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | 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-05-30 21:48:18 |
Message-ID: | CAH2-Wz=u6ZneLsnOMZ5U3oL+UBbotjM_E0w50H1=HRG19dijYg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 30, 2022 at 2:37 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> The results compare PG14 @ 0adff38d against master @ b3fb16e8b. In
> the chart, anything below 100% is a performance improvement over PG14
> and anything above 100% means PG15 is slower. You can see there's
> only the 64-byte / 64MB work_mem test that gets significantly slower
> and that there are only a small amount of other tests that are
> slightly slower. Most are faster and on average PG15 takes 90% of the
> time that PG14 took.
Shouldn't this be using the geometric mean rather than the arithmetic
mean? That's pretty standard practice when summarizing a set of
benchmark results that are expressed as ratios to some baseline.
If I tweak your spreadsheet to use the geometric mean, the patch looks
slightly better -- 89%.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-05-30 22:04:36 | Re: PG15 beta1 sort performance regression due to Generation context change |
Previous Message | David Rowley | 2022-05-30 21:37:16 | Re: PG15 beta1 sort performance regression due to Generation context change |