Horton

Re: A performance issue with Memoize

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-01-26T03:51:49Z
Lists: pgsql-hackers 
David Rowley <dgrowleyml@gmail.com> writes:
> I've adjusted the comments to what you mentioned and also leaned out
> the pretty expensive test case to something that'll run much faster
> and pushed the result.

+1, I was wondering if the test could be cheaper.  It wasn't horrid
as Richard had it, but core regression tests add up over time.

>> However ... it seems like we're not out of the woods yet.  Why
>> is Richard's proposed test case still showing
>> +         ->  Memoize (actual rows=5000 loops=N)
>> +               Cache Key: t1.two, t1.two
>> Seems like there is missing de-duplication logic, or something.

> This seems separate and isn't quite causing the same problems as what
> Richard wants to fix so I didn't touch this for now.

Fair enough, but I think it might be worth pursuing later.

			regards, tom lane

Commits

  1. Attempt to fix newly added Memoize regression test

  2. Compare varnullingrels too in assign_param_for_var().

  3. De-dupicate Memoize cache keys

  4. Improve NestLoopParam generation for lateral subqueries

  5. Avoid sharing PARAM_EXEC slots between different levels of NestLoop.