On Wed, Apr 13, 2016 at 3:47 PM, Andres Freund <andres@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
