Re: Foreign join pushdown vs EvalPlanQual
От | Robert Haas |
---|---|
Тема | Re: Foreign join pushdown vs EvalPlanQual |
Дата | |
Msg-id | CA+TgmoYmiswyMDyaRW1RoarTw8aP4wgJ0-bm4Lq-hJfY1WbYag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Foreign join pushdown vs EvalPlanQual (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: Foreign join pushdown vs EvalPlanQual
|
Список | pgsql-hackers |
On Fri, Oct 2, 2015 at 4:26 AM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > During join search, a joinrel should be comptible between local > joins and remote joins, of course target list also should be > so. So it is quite difficult to add wholerow resjunk for joinrels > before whole join tree is completed even if we allow row marks > that are not bound to base RTEs. Suppose ROW_MARK_COPY is in use, and suppose the query is: SELECT ft1.a, ft1.b, ft2.a, ft2.b FROM ft1, ft2 WHERE ft1.x = ft2.x; When the foreign join is executed, there's going to be a slot that needs to be populated with ft1.a, ft1.b, ft2.a, ft2.b, and a whole row reference. Now, let's suppose the slot descriptor has 5 columns: those 4, plus a whole-row reference for ROW_MARK_COPY. If we know what values we're going to store in columns 1..4, couldn't we just form them into a tuple to populate column 5? We don't actually need to be able to fetch such a tuple from the remote side because we can just construct it. I think. Is this a dumb idea, or could it work? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: