Re: PG15 beta1 sort performance regression due to Generation context change

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

In response to

Responses

Browse pgsql-hackers by date

  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