On Wed, Apr 13, 2016 at 3:47 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-04-13 15:21:31 -0500, Kevin Grittner wrote:
>> What is the kernel on which these tests were run? > > 3.16. I can upgrade to 4.4 if necessary. No, I'm not aware of any problems from 3.8 on. > But I still believe very strongly that this is side-tracking the issue. As long as I know it isn't a broken NUMA scheduler, or that there were fewer than four NUMA memory nodes, I consider it a non-issue. I just need to know whether it fits that problem profile to feel comfortable that I can interpret the results correctly. >> Which pg commit were these tests run against? > > 85e00470. + some reverts (the whitespace commits make this harder...) in > the reverted case. > > >> If 2201d801 was not included in your -1 tests, have you identified >> where the 2% extra run time is going on -1 versus reverted? > > No. It's hard to do good profiles on most virtualized hardware, since > hardware performance counters are disabled. So you only can do OS > sampling; which has a pretty big performance influence. > > I'm not entirely sure what you mean with "2201d801 was not included in > your -1 tests". The optimization was present. Sorry, the "not" was accidental -- I hate reverse logic errors like that. Based on the commit you used, I have my answer. Thanks. >> Since several other threads lately have reported bigger variation than >> that based on random memory alignment issues, can we confirm that this >> is a real difference in what is at master's HEAD? > > It's unfortunately hard to measure this conclusively here (and in > general). I guess we'll have to look, on native hardware, where the > difference comes from. The difference is smaller on my laptop, and my > workstation is somewhere on a container ship, other physical hardware I > do not have. OK, thanks. I can't think of anything else to ask for at this point. If you feel that you have enough to press for some particular course of action, go for it. Personally, I want to do some more investigation on those big machines. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
