| 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 |
| 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 |