Re: Organize working memory under per-PlanState context - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Organize working memory under per-PlanState context
Date
Msg-id 8e01848c-6618-4a20-a5c4-a975f5de3949@gmail.com
Whole thread Raw
In response to Re: Organize working memory under per-PlanState context  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On 20/8/2025 19:00, Jeff Davis wrote:
> On Wed, 2025-08-20 at 09:22 +0200, Andrei Lepikhov wrote:
>> I'm not sure I understand your reasoning clearly. How do you know
>> that
>> the current subtree will not be rescanned with the same parameter
>> set?
>> Building a hash table repeatedly may be pretty costly, no?
> 
> We can check the eflags for EXEC_FLAG_REWIND. That might not be the
> only condition we need to check, but we should know at plan time
> whether a subtree might be executed more than once.Postgres builds the plan tree from the bottom up, no? Estimating
costs
 
and choosing a specific operator at one level of the query tree, the 
planner never knows what will come next, on the upper level of this tree.
To work such problems out, in my 'optimiser support' extensions, I use 
one extra 'Top-Bottom' pass, reconsidering decisions that have been made 
based on information grabbed from the upper levels of the almost 
finished plan. Does your project move in a similar direction?

[1] https://github.com/danolivo/conf/blob/main/2025-MiddleOut/MiddleOut.pdf

-- 
regards, Andrei Lepikhov



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: ReplicationSlotRelease() crashes when the instance is in the single user mode
Next
From: jian he
Date:
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands