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

From Andrei Lepikhov
Subject Re: A performance issue with Memoize
Date
Msg-id dd90a086-c860-49f3-9e71-ac987e5ac522@postgrespro.ru
Whole thread Raw
In response to Re: A performance issue with Memoize  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: A performance issue with Memoize
List pgsql-hackers
On 30/10/2023 14:55, Richard Guo wrote:
> 
> On Thu, Oct 26, 2023 at 12:07 PM Andrei Lepikhov 
> <a.lepikhov@postgrespro.ru <mailto:a.lepikhov@postgrespro.ru>> wrote:
> 
>     Do you've thought about the case, fixed with the commit 1db5667? As I
>     see, that bugfix still isn't covered by regression tests. Could your
>     approach of a PARAM_EXEC slot reusing break that case?
> 
> 
> Hm, I don't think so.  The issue fixed by commit 1db5667 was caused by
> sharing PARAM_EXEC slots between different levels of NestLoop.  AFAICS
> it's safe to share PARAM_EXEC slots within the same level of NestLoop.
> 
> The change here is about sharing PARAM_EXEC slots between subquery's
> subplan_params and outer-relation variables, which happens within the
> same level of NestLoop.
> ...
> Did you notice a case that the change here breaks?
> 
> Hi Tom, could you share your insights on this issue and the proposed
> fix?

I think your patch works correctly so far. I mentioned the commit 
1db5667 because, as I see, the origin of the problem was parallel 
workers. I have thought about pushing Memoize down to a parallel worker 
and couldn't imagine whether such a solution would be correct.
Sorry if I disturbed you in vain.

-- 
regards,
Andrei Lepikhov
Postgres Professional




pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning
Next
From: Ashutosh Bapat
Date:
Subject: Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids)