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

From Robert Haas
Subject Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch)
Date
Msg-id CA+TgmoaQcd2qjWfhiH+b-u=78+SePRePxLCEzK7mHhpwyAP82w@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
On Thu, Oct 17, 2024 at 9:59 AM Shayon Mukherjee <shayonj@gmail.com> wrote:
> 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
CatalogTupleUpdateto 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
betweenthis and v1 [2] is that the update of pg_index row happens via CatalogTupleUpdate. 
>
> [1]  https://www.postgresql.org/message-id/20180618215635.m5vrnxdxhxytvmcm@alap3.anarazel.de
> [2] https://www.postgresql.org/message-id/EF2313B8-A017-4869-9B7F-A24EDD8795DE%40gmail.com

In-place updates are generally bad news, so I think this patch
shouldn't use them. However, someone will need to investigate whether
that breaks the indcheckxmin thing that Andres mentions in your [1],
and if it does, figure out what to do about it. Creating a test case
to show the breakage would probably be a good first step, to frame the
discussion.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: COPY performance on Windows
Next
From: Robert Haas
Date:
Subject: Re: MultiXact\SLRU buffers configuration