Re: hashagg slowdown due to spill changes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: hashagg slowdown due to spill changes
Date
Msg-id 20200724235114.xy4a2egntf7y7djh@alap3.anarazel.de
Whole thread Raw
In response to Re: hashagg slowdown due to spill changes  (Andres Freund <andres@anarazel.de>)
Responses Re: hashagg slowdown due to spill changes  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Hi,

On 2020-06-12 14:37:15 -0700, Andres Freund wrote:
> On 2020-06-11 11:14:02 -0700, Jeff Davis wrote:
> > On Thu, 2020-06-11 at 10:45 -0700, Andres Freund wrote:
> > > Did you run any performance tests?
> >
> > Yes, I reproduced your ~12% regression from V12, and this patch nearly
> > eliminated it for me.
> 
> I spent a fair bit of time looking at the difference. Jeff had let me
> know on chat that he was still seeing some difference, but couldn't
> quite figure out where that was.
> 
> Trying it out myself, I observed that the patch helped, but not that
> much. After a bit I found one major reason for why:
> LookupTupleHashEntryHash() assigned the hash to pointer provided by the
> caller's before doing the insertion. That ended up causing a pipeline
> stall (I assume it's store forwarding, but not sure). Moving the
> assignment to the caller variable to after the insertion got rid of
> that.

This is still not resolved. We're right now slower than 12. It's
effectively not possible to do performance comparisons right now. This
was nearly two months ago.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Row estimates for empty tables
Next
From: Andres Freund
Date:
Subject: Re: Improving connection scalability: GetSnapshotData()