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
