Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
| От | Mihail Nikalayeu |
|---|---|
| Тема | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
| Дата | |
| Msg-id | CADzfLwXMzv4_2Mc54qpASJ7FrKwQ6OsG0d9GxiYDxEKZ2KqHSA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements (Antonin Houska <ah@cybertec.at>) |
| Ответы |
Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
|
| Список | pgsql-hackers |
Hello, Antonin! On Tue, Dec 2, 2025 at 8:28 AM Antonin Houska <ah@cybertec.at> wrote: > I suppose you don't want to use logical decoding for CIC, do you? How can then > it be "the same" like in REPACK (CONCURRENTLY)? Or do you propose to rework > REPACK (CONCURRENTLY) from scratch so that it does not use logical decoding > either? My logic here chain is next: * looks like we may reuse snapshot reset technique for REPACK, using LR+some tricks * if it worked, why should we use reset technique + STIR (not LR too) in CIC? * mostly because it is not possible to active LR for some of tables * but there is (your) patch what aims to add the ability to activate LR for any table * if it worked - it feels natural to replace STIR by LR to keep things looking the same and working the same way While STIR may be more efficient and simple for CIC - it is still an additional entity in the PG domain, so LR may be a better solution from a system design perspective. But it is only thought so far, because I have not yet proved reset snapshot is possible for REPACK (need to do some POC at least). What do you think? Also, I think I'll extract reset-snapshot for CIC in a separate CF entry, since it still may be used with or without either STIR or LR. Best regards, MIkhail,
В списке pgsql-hackers по дате отправления: