From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | Sergey Soloviev <sergey(dot)soloviev(at)tantorlabs(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [BUG] Remove self joins causes 'variable not found in subplan target lists' error |
Date: | 2025-08-25 19:16:07 |
Message-ID: | 809743.1756149367@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Yeah. I think this is an oversight in create_unique_paths(): it's
> building an ORDER BY list without consideration for the possibility
> that some of the entries are known to be constant. In fact, because
> make_pathkeys_for_sortclauses will get rid of redundancies, this
> example actually ends up with a unique_rel whose unique_pathkeys
> are shorter than the unique_groupclause, which is pretty bogus.
Here is a patch that fixes it that way. I like this better than
Sergey's approach because it is making the plans better not worse.
There are a couple loose ends yet to be dealt with:
* The fact that we now avoid duplicate unique-ifications is good,
but I think it breaks the test case added by 44e95b572, since
that's no longer demonstrating what it set out to demonstrate.
(See the delta in aggregates.out.) I'm not sure that that's a
huge problem, but we probably at least ought to modify the comment
on that test case.
* What happens if we find that *all* the semi_rhs_exprs are known
constant? We'll compute empty pathkeys and groupClause, but then
what? It looks like create_final_unique_paths etc then build a
useless Unique step. Maybe we should just absorb the input
relation's path list as-is?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v3-fix-variable-not-found-in-subplan-target-lists.patch | text/x-diff | 9.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-08-25 19:24:07 | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
Previous Message | Peter Geoghegan | 2025-08-25 19:16:01 | Re: index prefetching |