| From: | Florin Irion <irionr(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Cc: | robertmhaas(at)gmail(dot)com |
| Subject: | pg_plan_advice: add NO_ scan and join method tags |
| Date: | 2026-07-02 16:35:24 |
| Message-ID: | 123bbb65-ae76-4112-b33d-864aca745b7b@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello,
The attached patch adds negative scan- and join-method advice to
pg_plan_advice. These tags are the complement of the existing
positive ones:
NO_SEQ_SCAN, NO_INDEX_SCAN, NO_INDEX_ONLY_SCAN,
NO_BITMAP_HEAP_SCAN, NO_TID_SCAN
NO_HASH_JOIN, NO_NESTED_LOOP (+ _PLAIN/_MATERIALIZE/_MEMOIZE),
NO_MERGE_JOIN (+ _PLAIN/_MATERIALIZE)
Each NO_ tag forbids the corresponding strategy for the named
relation, so the planner is free to choose any other one that is
eligible. In many cases this is more convenient than listing all the
methods you want, when in fact you only need to exclude a single one.
Some points about the design:
- The NO_ join tags keep the same join-order constraint as their
positive counterparts. NO_HASH_JOIN(x) means "use hash join or
merge join with x on the inner side", so x cannot become the
driving relation.
- Several NO_ tags for the same relation can be combined without
problem. A NO_ tag and a positive tag for the same method are in
conflict (both are marked as conflicting and neither is applied); a
NO_ tag and a positive tag for different methods are compatible.
- The scan NO_ tags use simple_target_list (no sublists), and the
join NO_ tags use generic_target_list, exactly as their positive
counterparts do.
Regression tests (no_scan, no_join) and documentation are included.
The patch applies on master and is pgindent-clean.
I would be glad to receive any feedback.
Thank you,
Florin
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-pg_plan_advice-Add-NO_SCAN-and-NO_JOIN_METHOD-tag.patch | text/plain | 54.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marcos Pegoraro | 2026-07-02 16:35:41 | Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements |
| Previous Message | Bryan Green | 2026-07-02 16:30:39 | pg_dump: use threads for parallel workers on all platforms |