Re: Should we cacheline align PGXACT?

On Thu, Sep 21, 2017 at 12:08 PM, Alexander Korotkov <
a(dot)korotkov(at)postgrespro(dot)ru> wrote:

> On Mon, Sep 18, 2017 at 12:41 PM, Daniel Gustafsson <daniel(at)yesql(dot)se>
> wrote:
>
>> > On 16 Sep 2017, at 01:51, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
>> wrote:
>> >
>> > On Tue, Sep 5, 2017 at 2:47 PM, Daniel Gustafsson <daniel(at)yesql(dot)se
>> <mailto:daniel(at)yesql(dot)se>> wrote:
>> > > On 04 Apr 2017, at 14:58, David Steele <david(at)pgmasters(dot)net <mailto:
>> david(at)pgmasters(dot)net>> wrote:
>> > >
>> > > On 4/4/17 8:55 AM, Alexander Korotkov wrote:
>> > >> On Mon, Apr 3, 2017 at 9:58 PM, Andres Freund <andres(at)anarazel(dot)de
>> <mailto:andres(at)anarazel(dot)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(at)1 -bselect-only(at)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