Horton
Menu

Re: pg_plan_advice

Nathan Bossart <nathandbossart@gmail.com>

View thread
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Alexander Lakhin <exclusion@gmail.com>, Lukas Fittl <lukas@fittl.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>, "heikki.linnakangas" <heikki.linnakangas@iki.fi>
Date: 2026-04-08T14:49:01Z
Lists: pgsql-hackers 
On Tue, Apr 07, 2026 at 06:05:47PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 0001 and 0002 implement the "retry a few times" idea for avoiding
>> test_plan_advice failures. I argue that (a) these are reasonable
>> post-commit stabilization that should not be blocked by feature freeze
>> and (b) most people here will be happier with a solution like this
>> that will normally cost very little than they will be with switching
>> test_plan_advice to executing serially. The RMT can decide whether it
>> agrees.
> 
> I'm not on the RMT, but I agree this is a nicer solution.
> (I didn't read these patches in detail, but in a quick once-over
> they seemed plausible.)
> 
>> The other question here is whether it's really a good idea to
>> apply this now considering that we've seen only one failure so far. I
>> think it's probably a good idea to do something like this before
>> release, so that we hopefully reduce the false positive rate from the
>> test to something much closer to zero, but I think we've still had
>> only the one failure, and I'm really interested in knowing how close
>> the failure rate is to zero already. The RMT may have an opinion on
>> how long to wait before doing something like this, too.
> 
> No strong opinion about that.  Certainly waiting a couple of weeks
> to gather more data seems reasonable.

I am only 1/3 of the RMT, but I am fine with the plan as stated.

-- 
nathan

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.