Re: Organize working memory under per-PlanState context

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Andrei Lepikhov <lepihov(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Organize working memory under per-PlanState context
Date: 2025-08-20 17:07:30
Message-ID: 1182219.1755709650@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Wed, 2025-08-20 at 09:22 +0200, Andrei Lepikhov wrote:
>> 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.

Side note: EXEC_FLAG_REWIND is defined as "you should be prepared
to handle REWIND efficiently". Not as "if this is off, you are
guaranteed not to see a REWIND". I'm not sure that this affects
what Jeff wants to do, but let's not be fuzzy about what information
is available at execution time.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2025-08-20 17:21:56 Re: Test instability when pg_dump orders by OID
Previous Message Tomas Vondra 2025-08-20 17:02:57 Re: Changing the state of data checksums in a running cluster