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

On Wed, Sep 23, 2026 at 1:17 PM Nikolay Samokhvalov <nik(at)postgres(dot)ai> wrote:
> 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;

Here's another set of patches, finally addressing this and your other
report, plus related problems that I found while digging around in
this area.

0001 fixes multiple problems with NO_GATHER advice. It's questionable
whether I've really defined NO_GATHER correctly, but I certainly
thought I had at the time I wrote the documentation, and yet the
behavior of the code does not match the documentation, and the
documentation is not as clear about all the details as it should be,
so this tries to clean some of that up without redefining anything too
much.

0002 arranges to suppress generation of plan advice from unflattened
set operations, which is what you reported on September 21st. Manually
written advice still won't work, but we can't enforce such advice
without new planner hooks, which is out of scope for this release.

0003 marks PARTITIONWISE(plain_table) advice inapplicable, which is
what you reported in this email. I think somebody could justifiably
take the position that this is not, strictly speaking, a bug fix,
because we should never generate PARTITIONWISE(plain_table), and
there's no meaningful way to do anything useful with it, so whatever.
However, when I initially coded this up, it caused a test failure,
because without 0f7dfd7936b9e99f9aeca00f52ab1692898ffff4 we actually
did generate such advice in a few regression test cases, but
apparently not in a way that changed the plan, so there was nothing in
the advice feedback for test_plan_advice to notice. With this commit,
if such bogus advice is generated, test_plan_advice sees the
"inapplicable" feedback and complains. So I think it's a good idea to
back-patch this into 19, because it's arguably a bug, and because
changing it also makes it easier to notice other bugs.

My plan is to get all of these committed and back-patched to
REL_19_STABLE before we wrap rc2. Thanks all for the reports, and
sorry it's taking me a while to grind through these. I really have
spent a lot of time on it, trust me...

--
Robert Haas
Databricks