Re: A performance issue with Memoize

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: A performance issue with Memoize
Дата
Msg-id CAApHDvpEOYQeVAt7VxcZc6m7mZqSBxFSPfDNSZzCBcATQrfNzw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A performance issue with Memoize  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: A performance issue with Memoize  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: A performance issue with Memoize  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Use of backup_label not noted in log
Следующее
От: Tom Lane
Дата:
Сообщение: Re: A performance issue with Memoize