Re: Retrieving unused tuple attributes in ExecScan

From: Andres Freund <andres(at)anarazel(dot)de>
To: "Ma, Marcus" <marcjma(at)amazon(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Retrieving unused tuple attributes in ExecScan
Date: 2022-06-27 19:52:46
Message-ID: 20220627195246.stkcxed27sczxak4@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

(please don't top-quote on PG lists)

On 2022-06-27 19:29:34 +0000, Ma, Marcus wrote:
> So I'm actually using the columns during merge join, basically I'm building a bloom filter on the outer relation and filtering out data on the inner relation of the join. I'm building the filter on the join keys, so the columns are being used further up the execution tree. However, even on a command like:
>
> Select * from t1 inner join t2 on t1.c1 = t2.c2;
>
> The execScan function returns slots that have (0, 0, 0) even though t1.c1 and t2.c2 will be used later on. I know that the Sort node and the MergeJoin node are able to read the actual values of the join keys, but for some reason the values aren't showing up on the SeqScan level. However, as soon as I add a qualification, such as:
>
> Select * from t1 inner join on t1.c1 = t2.c2 where t1.c1 % 2 = 0;
>
> The qualification makes the t1.c1 value show up during execScan, but not the t2.c2 value.

Slots can incrementally deform tuples. You need to call
slot_getsomeattrs(slot, number-up-to-which-you-need-tuples)
to reliably have columns deformed.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Finnerty, Jim 2022-06-27 20:12:41 Re: Retrieving unused tuple attributes in ExecScan
Previous Message Justin Pryzby 2022-06-27 19:36:09 Re: do only critical work during single-user vacuum?