| From: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [POC] Allow flattening of subquery with a link to upper query |
| Date: | 2022-09-02 11:08:55 |
| Message-ID: | 544c2280-7e02-461a-3d0c-7ae03ba462f2@postgrespro.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9/1/22 17:24, Richard Guo wrote:
>
> On Wed, Aug 31, 2022 at 2:35 PM Andrey Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)ru <mailto:a(dot)lepikhov(at)postgrespro(dot)ru>> wrote:
>
> Before flattening procedure we just look through the quals of subquery,
> pull to the upper level OpExpr's containing variables from the upper
> relation and replace their positions in the quals with true expression.
> Further, the flattening machinery works as usual.
>
> Hmm, I'm not sure this patch works correctly in all cases. It seems to
> me this patch pulls up the subquery without checking the constraints
> imposed by lateral references. If its quals contain any lateral
> references to rels outside a higher outer join, we would need to
> postpone quals from below an outer join to above it, which is probably
> incorrect.Yeah, it's not easy-to-solve problem. If I correctly understand the
code, to fix this problem we must implement the same logic, as
pull_up_subqueries (lowest_outer_join/safe_upper_varnos). It looks ugly.
But, more important, does this feature deserve such efforts/changes?
--
Regards
Andrey Lepikhov
Postgres Professional
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2022-09-02 11:55:11 | Re: Different compression methods for FPI |
| Previous Message | kuroda.hayato@fujitsu.com | 2022-09-02 11:06:17 | RE: test_decoding assertion failure for the loss of top-sub transaction relationship |