Re: Optimize WindowAgg's use of tuplestores

On Fri, 6 Sept 2024 at 18:30, Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)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