> 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.
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?