Re: pgbench more operators & functions - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench more operators & functions
Date
Msg-id alpine.DEB.2.20.1610081414370.15877@lancre
Whole thread Raw
In response to Re: pgbench more operators & functions  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: pgbench more operators & functions  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List 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.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: vacuumdb -f and -j options (was Question / requests.)
Next
From: Andreas Joseph Krogh
Date:
Subject: pg_upgrade 9.5 -> 9.6 fails when pg_largeobject is in separate tablespace