Re: A performance issue with Memoize - Mailing list pgsql-hackers

From David Rowley
Subject Re: A performance issue with Memoize
Date
Msg-id CAApHDvpEOYQeVAt7VxcZc6m7mZqSBxFSPfDNSZzCBcATQrfNzw@mail.gmail.com
Whole thread Raw
In response to Re: A performance issue with Memoize  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: A performance issue with Memoize
Re: A performance issue with Memoize
List pgsql-hackers
On Fri, 26 Jan 2024 at 07:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > I'd feel better about doing it your way if Tom could comment on if
> > there was a reason he put the function calls that way around in
> > 5ebaaa494.
>
> I'm fairly sure I thought it wouldn't matter because of the Param
> de-duplication done in paramassign.c.  However, Richard's example
> shows that's not so, because process_subquery_nestloop_params is
> picky about the param ID assigned to a particular Var while
> replace_nestloop_params is not.  So flipping the order makes sense.

Makes sense.

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.

> 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.

David



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Use of backup_label not noted in log
Next
From: Tom Lane
Date:
Subject: Re: A performance issue with Memoize