Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch) - Mailing list pgsql-hackers

From Rafia Sabih
Subject Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch)
Date
Msg-id CA+FpmFdvjw-HSQLv0x3JQKfhp_05EsY6jp7WEvVX32VHjp3mVw@mail.gmail.com
Whole thread Raw
In response to Proposal to Enable/Disable Index using ALTER INDEX  (Shayon Mukherjee <shayonj@gmail.com>)
List pgsql-hackers
Interesting idea. 
This patch needs a rebase.

On Thu, 17 Oct 2024 at 15:59, Shayon Mukherjee <shayonj@gmail.com> wrote:


On Oct 16, 2024, at 6:01 PM, Shayon Mukherjee <shayonj@gmail.com> wrote:

I'll take some time to think this through and familiarize myself with the new systable_inplace_update_begin. In the meantime, aside from the in-place updates on pg_index, I would love to learn any first impressions or feedback on the patch folks may have.


My take away from whether or not an in-place update is needed on pg_index [1]

- It’s unclear to me why it’s needed. 
- I understand the xmin would get incremented when using CatalogTupleUpdate to update indisenabled.
- However, I haven’t been able to replicate any odd behavior locally or CI. 
- FWIW - REINDEX CONCURRENTLY (via index_swap),  index_constraint_create and few other places perform CatalogTupleUpdate to update the relevant attributes as well.

Based on the above summary and after my testing I would like to propose a v3 of the patch. The only difference between this and v1 [2] is that the update of pg_index row happens via CatalogTupleUpdate.


Thank you for bearing with me on this :D
Shayon


--
Regards,
Rafia Sabih
CYBERTEC PostgreSQL International GmbH

pgsql-hackers by date:

Previous
From: Anthonin Bonnefoy
Date:
Subject: Re: Segfault in jit tuple deforming on arm64 due to LLVM issue
Next
From: Alvaro Herrera
Date:
Subject: doc fail about ALTER TABLE ATTACH re. NO INHERIT