Re: pg_*_advice: tsv load failure, etc.

From: Nikolay Samokhvalov <nik(at)postgres(dot)ai>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_*_advice: tsv load failure, etc.
Date: 2026-09-21 15:23:00
Message-ID: CAM527d-2cXkiGwvwGF_XkzazXgPcA6sU7KFekFD4VmFTtux-Xw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 9, 2026 at 4:16 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Generally, all of these problems stem from advice
> enforcement (which tries to make the plan obey the advice) being out
> of step with advice feedback (which says whether the plan actually did
> obey the advice). As far as I have found so far, those things are in
> lock step for all of the cases that test_plan_advice exercises, or to
> say it differently, they're in lock step for all the kinds of advice
> that pg_plan_advice generates itself.

AI found a related case and prepared the attached patch:
pg_plan_advice generates Gather advice for a set-operation upper relation
that it cannot enforce. This is on REL_19_STABLE at b368bdd2.

Reproducer:

load 'pg_plan_advice';
create table t (a int);
set max_parallel_workers_per_gather = 1;
set min_parallel_table_scan_size = 0;
set parallel_setup_cost = 0;
set parallel_tuple_cost = 0;
set enable_gathermerge = off;

explain (costs off, plan_advice)
select a from t union select a from t;

This produces a Gather above the Parallel Append and generates:

GATHER((unnamed_subquery unnamed_subquery#2))

Feeding that advice back already reports it as only partially matched:

set pg_plan_advice.advice =
'GATHER((unnamed_subquery unnamed_subquery#2))';
set parallel_setup_cost = 1000000;
explain (costs off)
select a from t union select a from t;

The second plan has no Gather, despite the supplied advice, and reports:

GATHER((unnamed_subquery unnamed_subquery#2)) /* partially matched */

The Gather belongs to the set-operation upper relation. That relation is
built by plan_set_operations(), where pg_plan_advice has no hook to enforce
the generated advice. This is also consistent with the documented
limitation that set-operation planning cannot currently be controlled.

The attached patch records which PlannerInfo objects contain set
operations, maps their RTIs into the final flattened range table, and
omits GATHER and GATHER_MERGE advice for those upper relations. It retains
Gather advice within set-operation input queries and for flattened union
all append relations.

I have not manually reviewed the C changes. The following passed:

make check
make -C src/test/isolation check
make -C contrib/pg_plan_advice check
make -C src/test/modules/test_plan_advice check

The pg_plan_advice regression additions cover union at the top level and
in a subquery, Gather within intersect inputs, and flattened union all.

--
Nik

Attachment Content-Type Size
0001-Don-t-emit-Gather-advice-for-set-operation-upper-rel.patch application/x-patch 7.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-09-21 15:25:02 Re: Write skew observed under serializable isolation
Previous Message Heikki Linnakangas 2026-09-21 15:21:30 Re: [Patch] Fix pg_get_multixact_stats() over-reporting members on a hot standby