Re: Optimize WindowAgg's use of tuplestores - Mailing list pgsql-hackers

From David Rowley
Subject Re: Optimize WindowAgg's use of tuplestores
Date
Msg-id CAApHDvr_qrgTkE0FQXGb_QaCNydnR5SX9sAtTNyHmwiowtNC+A@mail.gmail.com
Whole thread Raw
In response to Re: Optimize WindowAgg's use of tuplestores  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
On Fri, 6 Sept 2024 at 18:30, Ashutosh Bapat
<ashutosh.bapat.oss@gmail.com> wrote:
> If the patches are applied in the order 0001, 0003 and 0002, the size
> of the structure remains 632 throughout. Patch 0003 does not affect
> the size of the structure by itself.

Yeah. I kept 0003 separate so it could be easily tested independently.

> I have similar observations as yours on my amd64 laptop. I also
> verified that 0003 by itself is not effective. This indicates that the
> (atleast some of the) regression caused by 0002 comes from larger
> structure. Why would that happen?

I don't know the exact reason, but it could be something as simple as
having to load an additional cacheline that we previously didn't need
to load. Or, perhaps more cachelines are being modified and that slows
down some cache eviction code.  The PostgreSQL executor isn't very
friendly to CPU caches as we do tuple-at-a-time execution and
continually switch to other nodes. That requires accessing executor
states only briefly before switching to another node to bubble tuples
to the top of the plan.

> > Given the performance now seems improved in all cases, I plan on
> > pushing this change as a single commit.
> >
>
> Agreed. I will review the code in detail by next week.

Thanks, but I've already pushed these patches. I ended up pushing
v4-0001 as a separate commit. v4-0002 and v4-0003 went in as one. Feel
free to still have a look though.

David



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Refactoring postmaster's code to cleanup after child exit
Next
From: David Rowley
Date:
Subject: Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN