Re: Should we cacheline align PGXACT?

On Mon, Feb 13, 2017 at 7:07 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Alexander Korotkov wrote:
>
> > Yes, influence seems to be low. But nevertheless it's important to
> insure
> > that there is no regression here.
> > Despite pg_prewarm'ing and running tests 300s, there is still significant
> > variation.
> > For instance, with clients count = 80:
> > * pgxact-result-2.txt – 474704
> > * pgxact-results.txt – 574844
> > Could some background processes influence the tests? Or could it be
> > another virtual machine?
> > Also, I wonder why I can't see this variation on the graphs.
> > Another issue with graphs is that we can't see details of read and write
> > TPS variation on the same scale, because write TPS values are too low. I
> > think you should draw write benchmark on the separate graph.
>
> So, I'm reading that on PPC64 there is no effect, and on the "lesser"
> machine Tomas tested on, there is no effect either; this patch only
> seems to benefit Alexander's 72 core x86_64 machine.
>
> It seems to me that Andres comments here were largely ignored:
> https://www.postgresql.org/message-id/20160822021747.
> u5bqx2xwwjzac5u5(at)alap3(dot)anarazel(dot)de
> He was suggesting to increase the struct size to 16 bytes rather than
> going all the way up to 128. Did anybody test this?
>

Thank you for pointing. I'll provide such version of patch and test it on
72 core x86_64 machine.

> Re the coding of the padding computation, seems it'd be better to use
> our standard "offsetof(last-struct-member) + sizeof(last-struct-member)"
> rather than adding each of the members' sizes individually.
>

It was done so in order to evade extra level of nesting for PGXACT. See
discussion with Tom Lane in [1] and upthread.
Do you think we should introduce extra level of nesting or have better
ideas about how to evade it?

1. https://www.postgresql.org/message-id/19065.1471621560%40sss.pgh.pa.us

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company