Re: A performance issue with Memoize

On Fri, 26 Jan 2024 at 07:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <dgrowleyml(at)gmail(dot)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