Re: track needed attributes in plan nodes for executor use

On Mon, Jul 14, 2025 at 5:04 PM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> On 14/7/2025 06:52, Amit Langote wrote:
> > On Fri, Jul 11, 2025 at 11:09 PM Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
> > To support that efficiently, the slot can store a new tts_min_valid
> > field to indicate the lowest attno that needs deforming.
> > Alternatively, we could use a per-attribute flag array (with
> > TupleDesc->natts elements), though that adds some memory and
> > complexity. The first option seems simpler and should be sufficient in
> > most cases.
> I'm not sure. Typically, people don't optimise the order of columns, and
> it seems to me that necessary columns can be found both at the beginning
> of the table (like the primary key) and at the end. I believe it's best
> to skip any unused columns. However, I haven't seen your patch yet to
> talk about the effect.

Yeah, I agree that skipping arbitrary unused columns would be ideal.
For now though, I’m focusing on the fixed-not-null prefix case since
it’s easy to exploit with minimal runtime overhead -- if the minimum
needed attno is after a block of fixed-width not null columns, we can
skip deforming those with a single offset jump. Supporting arbitrary
column skipping would need something like a per-attribute flags array,
which might need someday, but wanted to start with something simpler.

> > I wasn’t quite sure what you meant about the CustomScan API, could you
> > elaborate?
>
> I was thinking that custom logic might require some columns that are not
> detected in the target list or qualifications. Therefore, there should
> be a method to provide the core with a list of the necessary columns.

I think I’m starting to understand the point. It’s not about the core
planner expressions, but about making sure that any expression
evaluated inside the custom scan node also has its needed attributes
marked. So even if the core plan doesn’t reference certain Vars, the
deforming logic still needs to know about them if the custom scan will
be evaluating expressions that access them. I’m still trying to fully
wrap my head around how that fits into the overall expression setup
and deformation path, but I agree that the custom node should have a
way to inform the executor about those needs.

--
Thanks, Amit Langote