Re: pgbench more operators & functions

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: pgbench more operators & functions
Дата
Msg-id CAJrrPGeR7QRsH_f5c-dJAW3QNmi8AvGBh1xbtUfwcmmtLRWXeQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgbench more operators & functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: pgbench more operators & functions  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: LOCK TABLE .. DEFERRABLE
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel execution and prepared statements