Ability to enable/disable indexes through GUC #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
shayonj
force-pushed
the
s/guc-based-disable-index
branch
24 times, most recently
from
b201bbf to
24daa35
Compare
The patch introduces a new GUC parameter `disabled_indexes` that allows users to specify a comma-separated list of indexes to be ignored during query planning. Key aspects: - Adds a new `isdisabled` attribute to the `IndexOptInfo` structure. - Modifies `get_relation_info` in `plancat.c` to skip disabled indexes entirely, thus reducing the number of places we need to check if an index is disabled or not. - Implements GUC hooks for parameter validation and assignment. - Resets the plan cache when the `disabled_indexes` list is modified through `ResetPlanCache()` I chose to modify the logic within `get_relation_info` as compared to, say, reducing the cost to make the planner not consider an index during planning, mostly to keep the number of changes being introduced to a minimum and also the logic itself being self-contained and easier to under perhaps (?). As mentioned before, this does not impact the building of the index. That still happens. I have added regression tests for: - Basic single-column and multi-column indexes - Partial indexes - Expression indexes - Join indexes - GIN and GiST indexes - Covering indexes - Range indexes - Unique indexes and constraints
shayonj
force-pushed
the
s/guc-based-disable-index
branch
from
24daa35 to
0821dec
Compare
shayonj
pushed a commit
that referenced
this pull request
Aug 9, 2025
If the number of sync requests is big enough, the palloc() call in
AbsorbSyncRequests() will attempt to allocate more than 1 GB of memory,
resulting in failure. This can lead to an infinite loop in the checkpointer
process, as it repeatedly fails to absorb the pending requests.
This commit introduces the following changes to cope with this problem:
1. Turn pending checkpointer requests array in shared memory into a bounded
ring buffer.
2. Limit maximum ring buffer size to 10M items.
3. Make AbsorbSyncRequests() process requests incrementally in 10K batches.
Even #2 makes the whole queue size fit the maximum palloc() size of 1 GB.
of continuous lock holding.
This commit is for master only. Simpler fix, which just limits a request
queue size to 10M, will be backpatched.
Reported-by: Ekaterina Sokolova <[email protected]>
Discussion: https://postgr.es/m/db4534f83a22a29ab5ee2566ad86ca92%40postgrespro.ru
Author: Maxim Orlov <[email protected]>
Co-authored-by: Xuneng Zhou <[email protected]>
Reviewed-by: Andres Freund <[email protected]>
Reviewed-by: Heikki Linnakangas <[email protected]>
Reviewed-by: Alexander Korotkov <[email protected]>
shayonj
pushed a commit
that referenced
this pull request
Aug 9, 2025
There've been a few complaints that it can be overly difficult to figure out why the planner picked a Memoize plan. To help address that, here we adjust the EXPLAIN output to display the following additional details: 1) The estimated number of cache entries that can be stored at once 2) The estimated number of unique lookup keys that we expect to see 3) The number of lookups we expect 4) The estimated hit ratio Technically #4 can be calculated using #1, #2 and #3, but it's not a particularly obvious calculation, so we opt to display it explicitly. The original patch by Lukas Fittl only displayed the hit ratio, but there was a fear that might lead to more questions about how that was calculated. The idea with displaying all 4 is to be transparent which may allow queries to be tuned more easily. For example, if #2 isn't correct then maybe extended statistics or a manual n_distinct estimate can be used to help fix poor plan choices. Author: Ilia Evdokimov <[email protected]> Author: Lukas Fittl <[email protected]> Reviewed-by: David Rowley <[email protected]> Reviewed-by: Andrei Lepikhov <[email protected]> Reviewed-by: Robert Haas <[email protected]> Discussion: https://postgr.es/m/CAP53Pky29GWAVVk3oBgKBDqhND0BRBN6yTPeguV_qSivFL5N_g%40mail.gmail.com
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The patch introduces a new GUC parameter
disabled_indexesthat allows users to specify a comma-separated list of indexes to be ignored during query planning. Key aspects:isdisabledattribute to theIndexOptInfostructure.get_relation_infoinplancat.cto skip disabled indexes entirely, thus reducing the number of places we need to check if an index is disabled or not.disabled_indexeslist is modified throughResetPlanCache()I chose to modify the logic within
get_relation_infoas compared to, say, reducing the cost to make the planner not consider an index during planning, mostly to keep the number of changes being introduced to a minimum and also the logic itself being self-contained and easier to under perhaps (?).As mentioned before, this does not impact the building of the index. That still happens.
I have added regression tests for: