Re: Wrong results from a parameterized Append

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

In response to

Responses

Browse pgsql-hackers by date

  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