Re: Retrieving unused tuple attributes in ExecScan
От | Andres Freund |
---|---|
Тема | Re: Retrieving unused tuple attributes in ExecScan |
Дата | |
Msg-id | 20220627195246.stkcxed27sczxak4@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Retrieving unused tuple attributes in ExecScan ("Ma, Marcus" <marcjma@amazon.com>) |
Ответы |
Re: Retrieving unused tuple attributes in ExecScan
|
Список | 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 filteringout data on the inner relation of the join. I'm building the filter on the join keys, so the columns are being usedfurther 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 thatthe Sort node and the MergeJoin node are able to read the actual values of the join keys, but for some reason the valuesaren'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
В списке pgsql-hackers по дате отправления: