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-23 17:17:06
Message-ID: CAM527d_fz=OmHSznp3nx_sc2KG9hKb5mHoVRt5jsgsuM9G9hdg@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).

AI found another case and prepared the attached patch. A single-target
PARTITIONWISE entry on a plain table disables every scan path,
although the advice only says that the table must not participate in a
partitionwise join.

load 'pg_plan_advice';
create table plain (i int);
set pg_plan_advice.advice = 'PARTITIONWISE(plain)';
explain (costs off, plan_advice) select * from plain;

This produces:

Seq Scan on plain
Disabled: true
Supplied Plan Advice:
PARTITIONWISE(plain) /* matched, failed */

pgpa_planner_apply_scan_advice() treats this single-target PARTITIONWISE
entry as an Append/MergeAppend scan restriction. For the plain table,
that clears all available scan methods. The feedback walker then
looks for a partitionwise scan and reports failure.

The patch uses the preprocessed RTE inheritance flag to treat this as a
matched no-op. It also handles the equivalent PARTITIONWISE((plain)) form.
This is on REL_19_STABLE at b73d13c3, and the patch applies cleanly to
master at 374522aa.

I have not manually reviewed the C changes. The pg_plan_advice regression
suite, its foreign-scan TAP test, and the test_plan_advice TAP test pass.

Nik

Attachment Content-Type Size
0001-pg_plan_advice-Make-PARTITIONWISE-on-plain-tables-a-no-op.patch application/x-patch 6.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2026-09-23 17:18:20 Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten
Previous Message Sehrope Sarkuni 2026-09-23 17:16:45 Re: Speed up lpad() and rpad() for one-byte padding strings