From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Finnerty, Jim" <jfinnert(at)amazon(dot)com> |
Subject: | Re: Making Vars outer-join aware |
Date: | 2022-07-12 07:20:37 |
Message-ID: | CAMbWs4-0cdVpgY0c2uULBCX2vPjQt3Fx3=XFZh-Mn=UWmxhG-A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 11, 2022 at 3:38 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Here's v2 of this patch series. It's functionally identical to v1,
> but I've rebased it over the recent auto-node-support-generation
> changes, and also extracted a few separable bits in hopes of making
> the main planner patch smaller. (It's still pretty durn large,
> unfortunately.) Unlike the original submission, each step will
> compile on its own, though the intermediate states mostly don't
> pass all regression tests.
Noticed a different behavior from previous regarding PlaceHolderVar.
Take the query below as an example:
select a.i, ss.jj from a left join (select b.i, b.j + 1 as jj from b) ss
on a.i = ss.i;
Previously the expression 'b.j + 1' would not be wrapped in a
PlaceHolderVar, since it contains a Var of the subquery and meanwhile it
does not contain any non-strict constructs. And now in the patch, we
would insert a PlaceHolderVar for it, in order to have a place to store
varnullingrels. So the plan for the above query now becomes:
# explain (verbose, costs off) select a.i, ss.jj from a left join
(select b.i, b.j + 1 as jj from b) ss on a.i = ss.i;
QUERY PLAN
----------------------------------
Hash Right Join
Output: a.i, ((b.j + 1))
Hash Cond: (b.i = a.i)
-> Seq Scan on public.b
Output: b.i, (b.j + 1)
-> Hash
Output: a.i
-> Seq Scan on public.a
Output: a.i
(9 rows)
Note that the evaluation of expression 'b.j + 1' now occurs below the
outer join. Is this something we need to be concerned about?
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo NAGATA | 2022-07-12 07:29:51 | Re: Support TRUNCATE triggers on foreign tables |
Previous Message | John Naylor | 2022-07-12 06:57:48 | Re: [PATCH] Optimize json_lex_string by batching character copying |