Re: PostgresSQL 13.0 Beta 1 on Phoronix - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: PostgresSQL 13.0 Beta 1 on Phoronix
Date
Msg-id CAEudQArvqYnwJ30Md1xWGL_yyjccDCysM_jan8-bGTTjQMDO0w@mail.gmail.com
Whole thread Raw
In response to Re: PostgresSQL 13.0 Beta 1 on Phoronix  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Em seg., 25 de mai. de 2020 às 03:57, Michael Paquier <michael@paquier.xyz> escreveu:
On Sun, May 24, 2020 at 02:50:08PM -0300, Ranier Vilela wrote:
> Em dom., 24 de mai. de 2020 às 14:34, Peter Geoghegan <pg@bowt.ie> escreveu:
>> It looks like they're only running pgbench for 60 second runs in all
>> configurations -- notice that "-T 60" is passed to pgbench. I'm not
>> entirely sure that that's all that there is to it. Still, there isn't
>> any real attempt to make it clear what's going on here. I have my
>> doubts about how representative these numbers are for that reason.
>
> I also find it very suspicious.

I don't know, but what seems pretty clear to me is this benchmark does
zero customization of postgresql.conf (it disables autovacuum!?), and
that the number of connections is calculated based on the number of
cores while the scaling factor is visibly calculated from the amount
of memory available in the environment.  Perhaps the first part is
wanted, but we are very conservative to allow PG to work on small-ish
machines with the default configuration, and a 56-core machine with
378GB of memory is not something I would define as small-ish.
Does this mean that V13 would need additional settings in postgresql.conf,
to perform better than V12, out of the box?
If there is any new feature in V13 that needs some configuration in postgresql.conf,
Would be bettert it should be documented or configured in the installation itself,
to avoid this type of misunderstanding, which harms the perception of Postgres.
 
regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: some grammar refactoring
Next
From: Tomas Vondra
Date:
Subject: Re: Trouble with hashagg spill I/O pattern and costing