Re: A performance issue with Memoize

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: A performance issue with Memoize
Date: 2023-10-25 06:40:58
Message-ID: CAMbWs4-3oaHkAENPYn-qg8XhBv3WnwbSGq07GDf-j0=dM-jZ3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 20, 2023 at 6:40 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:

> I haven't thought thoroughly about the fix yet. But one way I'm
> thinking is that in create_subqueryscan_plan() we can first add the
> subquery's subplan_params to root->curOuterParams, and then replace
> outer-relation Vars in scan_clauses afterwards. That can make us be
> able to share the same PARAM_EXEC slot for the same Var that both
> belongs to the subquery's uplevel vars and to the NestLoop's
> outer-relation vars. To be concrete, something like attached.
>

After some more thought, I think this is the right way to fix this
issue. The idea here is to make sure that the same NLP Var shares the
same PARAM_EXEC slot. This change can also help to save PARAM_EXEC
slots (which is trivial though since slots are very cheap).

Thanks
Richard

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2023-10-25 06:45:59 Re: A performance issue with Memoize
Previous Message jian he 2023-10-25 06:14:34 Re: SQL:2011 application time