Re: pgbench more operators & functions

Haribabu Kommi <kommi.haribabu@gmail.com>

From: Haribabu Kommi <kommi.haribabu@gmail.com>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>, PostgreSQL Developers <pgsql-hackers@postgresql.org>
Date: 2016-12-02T04:56:29Z
Lists: pgsql-hackers
On Sat, Oct 8, 2016 at 11:27 PM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

>
> 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:-(
>
>
The current status of the patch and recent mail thread discussion doesn't
represent the same.

Closed in 2016-11 commitfest with "returned with feedback" status.
Please feel free to update the status once you submit the updated patch.

Regards,
Hari Babu
Fujitsu Australia

Commits

  1. Improve scripting language in pgbench