| 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> |
| Subject: | Re: Wrong results from a parameterized Append |
| Date: | 2026-10-24 01:27:07 |
| Message-ID: | CAMbWs49P-hxy2SXRiEwCuSq+OMw0CkZAuAJd5pd3urA64XGm7g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Oct 10, 2026 at 4:13 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> However, there are a number of places in the memoize logic that
> think they can use ppi_clauses, which seems about as unsafe.
> I think that'll at worst cause some missed optimization chances,
> but I'm not entirely certain.
I agree it's at worst a missed optimization. Joinrels and non-baserel
appendrels have NIL ppi_clauses and no lateral_vars, so
get_memoize_path() finds no cache key and we never build a Memoize on
top of them. A baserel appendrel can list a clause the Append doesn't
enforce, but such a clause references both sides, so
clause_sides_match_join() rejects it. In my example that costs us a
Memoize keyed on t1.b alone, and on that plan master drops the join
clause while v2 keeps it.
> Another interesting point is that Gather and GatherMerge are treated
> like baserel paths, although what's under them might be a join or
> append. This might be okay but I'm not quite convinced there either.
> At least we probably should document this somewhere.
I think this is OK. All callers of create_gather_path() and
create_gather_merge_path() pass required_outer = NULL, and we don't
generate parameterized partial paths, so a Gather/GatherMerge path
never has param_info. v3 adds an Assert plus a comment for this.
> The fact that create_append_path sometimes uses
> get_baserel_parampathinfo isn't reflected in my new comments either,
> and I wonder if the fact that it does isn't breaking
> get_param_path_clause_serials.
That's where the bogus serial comes from. In my example the
appendrel's ppi_serials includes "t1.a = s.a + t1.b", while the
intersection over its children is empty. A bare AppendPath is fine
since we intersect the children; only the wrappers were wrong, which
v2 fixes. v3 notes this in the comments for ParamPathInfo and
create_append_path.
Attached is v3. It also replaces the test case with a UNION ALL query
that gives wrong results on v16 as well as master.
- Richard
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-Look-through-wrapper-paths-when-collecting-enforc.patch | application/octet-stream | 20.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-10-24 03:48:21 | Re: Wrong results from a parameterized Append |
| Previous Message | Henson Choi | 2026-10-24 01:06:52 | Re: [DEPARSE] A COLLATE clause in the URI of XMLNAMESPACES does not read back |