Re: BUG #19804: "variable not found in subplan target list", DISTINCT agg over Gather`

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: alpkeles99(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19804: "variable not found in subplan target list", DISTINCT agg over Gather`
Date: 2026-10-30 08:08:30
Message-ID: CAHewXN=w6BjEHDfkC5ZTzc35FHHDc=KE8Nkw=Yj_3_K-VvVRNw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 于2026年10月30日周五 00:17写道:
>
> It looks to me like prepare_sort_from_pathkeys() could look at
> the subplan(s) of the given Plan node to see what they are actually
> returning, but I wonder whether it'd be better to change its API
> to have the caller specify what the input is. We're going to have
> to modify the way that create_append_plan does this in any case,
> since right now it does prepare_sort_from_pathkeys() on the Append
> plan before it's attached any child plans.
>
> The comment for relation_can_be_sorted_early looks like that function
> might need rejiggering too, if prepare_sort_from_pathkeys starts to
> behave differently. I didn't look closely though.

Thanks for the explanation. Attached is a WIP patch following your
suggestion to pass the available projection inputs explicitly to
prepare_sort_from_pathkeys().

The patch leaves find_computable_ec_member() unchanged. Instead, the
caller supplies independently available Vars and quasi-Vars, without
extracting Vars from computed child output expressions.
For the reported query, the Gather's child outputs b.y * 2 and a.x, so
the available input list contains a.x but not b.y. This makes EC
selection choose a.x + 1.

For Append and MergeAppend, the patch builds the child plans first and
prepares their sort columns using the concrete plans.
The parent targetlist determines the common column positions, since
distinct parent columns can translate to identical expressions in one
UNION ALL child.
The sort metadata is then obtained from the first child and checked
against the remaining children.

Collecting the inputs also needs some additional handling for
outer-join nullingrels, nestloop parameters, and PHVs evaluated
locally.
For outer joins, the patch allows output Vars and PHVs to have a
superset of the input's nullingrels.
I am less certain that the local PHV handling is the best approach,
and would appreciate your thoughts on that part.

I also adjusted relation_can_be_sorted_early(). It still accepts a
directly matching reltarget expression, but its computability fallback
now considers only independently exposed Vars and quasi-Vars.
This is conservative because no particular Plan is available to
inspect at that stage; it might reject some otherwise valid early-sort
opportunities.

The reported case is fixed, and all regression tests pass with
assertions enabled.

This has become a larger change than I expected, so I am sending it as
WIP to get feedback.

--
Thanks,
Tender Wang

Attachment Content-Type Size
WIP-Supply-valid-input-Vars-for-sort-EC-selection.patch text/plain 34.7 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2026-10-30 08:41:20 Re: BUG #19763: ManualBug2 NULL pointer dereference in make_build_data via examine_expression bypass of lookup_var_a
Previous Message 飞鱼 2026-10-30 07:54:36 Re: BUG #19805: Wrong results: self-join elimination drops an ORDER BY sort key with GROUPING SETS / CUBE / ROLLUP