Re: Organize working memory under per-PlanState context

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