On Mon, Feb 13, 2017 at 7:07 PM, Alvaro Herrera <alvhe...@2ndquadrant.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. > u5bqx2xwwjzac...@alap3.anarazel.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
