Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch)
От | Rafia Sabih |
---|---|
Тема | Re: Proposal to Enable/Disable Index using ALTER INDEX (with patch) |
Дата | |
Msg-id | CA+FpmFdvjw-HSQLv0x3JQKfhp_05EsY6jp7WEvVX32VHjp3mVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Proposal to Enable/Disable Index using ALTER INDEX (Shayon Mukherjee <shayonj@gmail.com>) |
Список | 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 :DShayon
Regards,
Rafia Sabih
Rafia Sabih
CYBERTEC PostgreSQL International GmbH
В списке pgsql-hackers по дате отправления: