Re: pg_plan_advice

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Jakub Wartak <jakub.wartak@enterprisedb.com>
Cc: Lukas Fittl <lukas@fittl.com>, Jacob Champion <jacob.champion@enterprisedb.com>, Dian Fay <di@nmfay.com>, Matheus Alcantara <matheusssilv97@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-01-14T22:11:11Z
Lists: pgsql-hackers
On Wed, Jan 14, 2026 at 6:02 AM Jakub Wartak
<jakub.wartak@enterprisedb.com> wrote:
> a) q4.sql (please see attached file for repro). More or less: right
> after import I get a hard failure if the earlier recommended advice is
> enabled (smells like a bug to me: we shouldn't get any errors even if
> advice is bad). This can be solved by ANALYZE, but brought up back by
> truncating pg_statistics
> ERROR:  unique semijoin found for relids (b 3) but not observed during planning
> STATEMENT:  explain (timing off, costs off, settings off, memory off)

Hmm, so the plan tree walker thinks that we did a semijoin between
lineitem and orders by making lineitem unique on the join column and
then performing a regular join. That appears to be correct. But
pgpa_join_path_setup never created a pgpa_join_path_setup for that
possibility, or created one that doesn't actually match up properly to
what was found in the plan tree. Can you check whether a
pgpa_sj_unique_rel gets created in pgpa_join_path_setup, and with what
contents?

> a) q8.sql (please see attached file for demo). It is even more
> bizarre, happens right after import , fixed by ANALYZE, but even
> TRUNCATING pg_statistic doesnt bring back the problem. Pinpointed that
> additional pg_clear_relation_stats() triggers the problem back.

I found this one. I now think that
pgpa_planner_apply_join_path_advice() shouldn't added anything to
jo_permit_indexes when a join method hint implicitly permits a join
order. I simplified your test case to this:

set pg_plan_advice.advice = 'JOIN_ORDER(n1 region customer)
NESTED_LOOP_PLAIN(region)';
explain (costs off, plan_advice)
    SELECT
        n1.n_name AS nation
    FROM
        customer,
        nation n1,
        region
    WHERE
        c_nationkey = n1.n_nationkey
        AND n1.n_regionkey = r_regionkey
        AND r_name = 'AMERICA';

What was happening here is that when we considered a join between
{customer, nation} and region, pgpa_planner_apply_join_path_advice()
said, well, according to the JOIN_ORDER advice, this join order is not
allowed, which is correct. And, according to the NESTED_LOOP_PLAIN
advice, this join order is allowed, which is also correct, because
NESTED_LOOP_PLAIN(region) denies join orders where region is the
driving table, since those would make it impossible to respect the
advice, and this join order doesn't do that. Then, it concludes that
because one piece of advice says the join order is OK and the other
says it isn't, the advice conflicts. This is where I think it's going
off the rails: the NESTED_LOOP_PLAIN() advice should only be allowed
to act as a negative constraint, not a positive one. So what I did is:

diff --git a/contrib/pg_plan_advice/pgpa_planner.c
b/contrib/pg_plan_advice/pgpa_planner.c
index 13f81e9b063..95dd71deb84 100644
--- a/contrib/pg_plan_advice/pgpa_planner.c
+++ b/contrib/pg_plan_advice/pgpa_planner.c
@@ -982,7 +982,6 @@ pgpa_planner_apply_join_path_advice(JoinType
jointype, uint64 *pgs_mask_p,
                 jo_deny_indexes = bms_add_member(jo_deny_indexes, i);
             else if (restrict_method)
             {
-                jo_permit_indexes = bms_add_member(jo_permit_indexes, i);
                 jm_indexes = bms_add_member(jm_indexes, i);
                 if (join_mask != 0 && join_mask != my_join_mask)
                     jm_conflict = true;
@@ -1038,8 +1037,6 @@ pgpa_planner_apply_join_path_advice(JoinType
jointype, uint64 *pgs_mask_p,
                 }
                 else if (advice_unique != jt_unique)
                     jo_deny_indexes = bms_add_member(jo_deny_indexes, i);
-                else
-                    jo_permit_indexes = bms_add_member(jo_permit_indexes, i);
             }
             continue;
         }

> To me it looks like "pps" is NULL and hits "if
> (pps->generate_advice_string)" because
> GetPlannerGlobalExtensionState() returns NULL because
> root->glob->extension_state_allocated is 0 (while planner_extension_id
> is also 0). Crash is only happening for q20 and q4, till I've tried
> the below fixup which seems to solve it (?) - it's just based on the
> fact that all other uses of GetPlannerGlobalExtensionState() seem to
> check for NULL:
>
> -               if (pps->generate_advice_string)
> +               if (pps != NULL && pps->generate_advice_string)

Agreed, will incorporate that fix.

> 3b) XXX - marker:I was looking for a solution and apparently cfbot
> farm has those options, so they should be testing it anyway. And this
> brings me to a fact, that it maybe could be detected by cfbot, however
> the $thread is not registered so cfbot had no chance to see what's
> more there? (I'm mainly thinking about any cross-platform issues, if
> any).

I mean, there is https://commitfest.postgresql.org/patch/6184/

-- 
Robert Haas
EDB: http://www.enterprisedb.com



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. pg_plan_advice: Fix another unique-semijoin bug.

  2. pg_plan_advice: Export feedback-related definitions.

  3. pg_plan_advice: Fix a bug when a subquery is pruned away entirely.

  4. pg_plan_advice: Add alternatives test to Makefile.

  5. pg_plan_advice: Handle non-repeatable TABLESAMPLE scans.

  6. pg_stash_advice: Allow stashed advice to be persisted to disk.

  7. Add pg_stash_advice contrib module.

  8. pg_plan_advice: Avoid assertion failure with partitionwise aggregate.

  9. pg_plan_advice: Invent DO_NOT_SCAN(relation_identifier).

  10. Add an alternative_plan_name field to PlannerInfo.

  11. pg_plan_advice: Refactor to invent pgpa_planner_info

  12. Respect disabled_nodes in fix_alternative_subplan.

  13. get_memoize_path: Don't exit quickly when PGS_NESTLOOP_PLAIN is unset.

  14. test_plan_advice: Set TAP test priority 50 in meson.build.

  15. pg_plan_advice: Avoid a crash under GEQO.

  16. Test pg_plan_advice using a new test_plan_advice module.

  17. pg_plan_advice: Always install pg_plan_advice.h, and in the right place

  18. pg_plan_advice: Fix failures to accept identifier keywords.

  19. Add pg_plan_advice contrib module.

  20. Allow extensions to mark an individual index as disabled.

  21. Replace get_relation_info_hook with build_simple_rel_hook.

  22. Store information about Append node consolidation in the final plan.

  23. Store information about elided nodes in the final plan.

  24. Store information about range-table flattening in the final plan.

  25. Pass cursorOptions to planner_setup_hook.

  26. Fix PGS_CONSIDER_NONPARTIAL interaction with Materialize nodes.

  27. Fix mistakes in commit 4020b370f214315b8c10430301898ac21658143f

  28. Allow for plugin control over path generation strategies.

  29. Update some comments for fasthash

  30. Allow passing a pointer to GetNamedDSMSegment()'s init callback.

  31. Don't reset the pathlist of partitioned joinrels.

  32. Treat number of disabled nodes in a path as a separate cost metric.