Re: pgbench more operators & functions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench more operators & functions
Date: 2016-10-08 12:27:05
Message-ID: alpine.DEB.2.20.1610081414370.15877@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Amit.

>> Also, given the heavy UPDATE nature of the pgbench test, a non 100% default
>> fill factor on some tables would make sense.
>
> FWIW, sometime back I have seen that with fill factor 80, at somewhat
> moderate client counts (32) on 192 - Hyper Threaded m/c, the
> performance is 20~30% better, but at higher client counts, it was same
> as 100 fill factor.

The 20-30% figure is consistent with figures I collected 2 years ago about
fill factor on HDD, see the beginning run of:

http://blog.coelho.net/database/2014/08/23/postgresql-fillfactor-and-update.html

Although I found that the advantages is reduced after some time because
once a page has got an update it has some free space which can be taken
advantage of later on, if the space was not reclaimed by vacuum.

I cannot understand why there would be no advantage with more clients,
though...

Alas, performance testing is quite sensitive to many details:-(

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Joseph Krogh 2016-10-08 13:02:00 pg_upgrade 9.5 -> 9.6 fails when pg_largeobject is in separate tablespace
Previous Message Michael Paquier 2016-10-08 12:22:07 Re: vacuumdb -f and -j options (was Question / requests.)