Re: [HACKERS] Should we cacheline align PGXACT?

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: [HACKERS] Should we cacheline align PGXACT?
Дата
Msg-id CAPpHfdtrbEFfT9BQ5D762QSdKhkFTewJ_+vEC=L6oHCu5JcE8w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Should we cacheline align PGXACT?  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список pgsql-hackers
On Thu, Sep 21, 2017 at 12:08 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
On Mon, Sep 18, 2017 at 12:41 PM, Daniel Gustafsson <daniel@yesql.se> wrote:
> On 16 Sep 2017, at 01:51, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
>
> On Tue, Sep 5, 2017 at 2:47 PM, Daniel Gustafsson <daniel@yesql.se <mailto:daniel@yesql.se>> wrote:
> > On 04 Apr 2017, at 14:58, David Steele <david@pgmasters.net <mailto:david@pgmasters.net>> wrote:
> >
> > On 4/4/17 8:55 AM, Alexander Korotkov wrote:
> >> On Mon, Apr 3, 2017 at 9:58 PM, Andres Freund <andres@anarazel.de <mailto:andres@anarazel.de>
> >>
> >>    I'm inclined to push this to the next CF, it seems we need a lot more
> >>    benchmarking here.
> >>
> >> No objections.
> >
> > This submission has been moved to CF 2017-07.
>
> This CF has now started (well, 201709 but that’s what was meant in above), can
> we reach closure on this patch in this CF?
>
> During previous commitfest I come to doubts if this patch is really needed when same effect could be achieved by another (perhaps random) change of alignment.  The thing I can do now is to retry my benchmark on current master and check what effect this patch has now.

Considering this I’ll mark this as Waiting on Author, in case you come to
conclusion that another patch is required then we’ll bump to a return status.

I've made some read-only benchmarking.  There is clear win in this case.  The only point where median of master is higher than median of patched version is 40 clients.

In this point observations are following:
master:       982432 939483 932075
pgxact-align: 913151 921300 938132
So, groups of observations form the overlapping ranges, and this anomaly can be explained by statistical error.

I'm going to make some experiments with read-write and mixed workloads too.

I've made benchmarks with two more workloads.
scalability-rw.png – read-write tcpb-like workload (pgbench default)
scalability-rrw.png – 90% read-only transactions 10% read-write transactions (-btpcb-like@1 -bselect-only@9)
It became clear that this patch causes regression.  On pure read-write workload, it's not so evident due to high variability of observations.  However, on mixed workload it's very clear regression.
I would be ridiculous to consider patch which improves read-only performance but degrades read-write performance in nearly same degree.  Thus, this topic needs more investigation if it's possible to at least get the same benefit on read-only workload without penalty on read-write workload (ideally read-write workload should benefit too).  I'm going to mark this patch as "returned with feedback".

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 
Вложения

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

Предыдущее
От: Amit Khandekar
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [HACKERS] Windows warnings from VS 2017