Introduce the ability to set index visibility using ALTER INDEX #1
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.
This patch introduces index visibility control using ALTER INDEX and CREATE INDEX
commands.
Original motivation for the problem and proposal for a patch
can be found at [1].
This patch passes all the existing specs and the newly added regression tests. The patch
is ready for review and test. It compiles, so the patch can be applied for testing as well.
Note: The patch has gone through a few iterations. Earlier versions of the patch had the ENABLE/DISABLE grammar.
The current version has the VISIBLE/INVISIBLE grammar. So, you will the local variable names using the new grammar accordingly.
Implementation details:
New Grammar:
Default state is visible. Indexes are only invisible when explicitly
instructed via CREATE INDEX ... INVISIBLE or ALTER INDEX ... INVISIBLE.
Primary Key and Unique constraint indexes are always visible. The
VISIBLE/INVISIBLE grammar is supported for these types of indexes and they can
be made invisible via ALTER INDEX ... INVISIBLE.
ALTER INDEX ... VISIBLE/INVISIBLE performs update on the relevant row in pg_index
catalog
pg_get_indexdef() supports the new functionality and grammar. This change is
reflected in \d output for tables and pg_dump. We show the INVISIBLE syntax accordingly.
Added force_invisible_index GUC parameter that forces the planner to use invisible
indexes. This is useful for testing and validating index behavior without changing
their visibility state. Based on feedback from Sami S [2]
Updated create_index.sql regression test to cover the new grammar and verify
that invisible indexes are not used in queries. The test covers:
Adds a new indisvisible attribute to the IndexOptInfo structure.
Modifies get_relation_info in plancat.c to skip invisible indexes entirely, thus reducing the number of places we need to check if an index is invisible or not. Inspired by the conversations start at [3].
No changes are made to stop the index from getting maintained. This way we ensure no
data loss or corruption when index is made visible again.
TOAST indexes are supported and visible by default as well.
REINDEX CONCURRENTLY is supported as well and existing state of pg_index.indisvisible
is carried over accordingly.
See the changes in create_index.sql to get an idea of the grammar and sql statements.
See the changes in create_index.out to get an idea of the catalogue states and EXPLAIN
output to see when an index is getting used or isn't (when invisible).
Incorporated DavidR's feedback from [4] around documentation and also you will see that by skipping invisible indexes entirely from get_relation_info in plancat.c (as mentioned above), we address the other mentioned issues as well.
Lastly, protects against the case where indcheckxmin is true by raising ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE.
Supports index visibility status on \d (h/t to Benoit Lobréau for the patch)
Looking forward to any and all feedback on this patch, including but not limited to code quality, tests, fundamental logic.
[1] https://www.postgresql.org/message-id/CANqtF-oXKe0M%3D0QOih6H%2BsZRjE2BWAbkW_1%2B9nMEAMLxUJg5jA%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CAA5RZ0udzydObMDi65C59-oq54B9ZmjSZ1wVH3h%2Bv4XiVm6QDA%40mail.gmail.com
[3] https://www.postgresql.org/message-id/3465209.1727202064%40sss.pgh.pa.us
[4] https://www.postgresql.org/message-id/CAApHDvpUNu%3DiVcdJ74sypvgeaCF%2Btfpyb8VRhZaF7DTd1xVr7g%40mail.gmail.com