Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
От | Matthias van de Meent |
---|---|
Тема | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
Дата | |
Msg-id | CAEze2WgNHTWfw_bP6O0zW_=vi1D-yi1nh6-JDj9kd=8UaB-zLA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements (Michail Nikolaev <michail.nikolaev@gmail.com>) |
Ответы |
Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
|
Список | pgsql-hackers |
On Wed, 21 Feb 2024 at 09:35, Michail Nikolaev <michail.nikolaev@gmail.com> wrote: > > One more idea - is just forbid HOT prune while the second phase is > running. It is not possible anyway currently because of snapshot held. > > Possible enhancements: > * we may apply restriction only to particular tables > * we may apply restrictions only to part of the tables (not yet > scanned by R/CICs). > > Yes, it is not an elegant solution, limited, not reliable in terms of > architecture, but a simple one. How do you suppose this would work differently from a long-lived normal snapshot, which is how it works right now? Would it be exclusively for that relation? How would this be integrated with e.g. heap_page_prune_opt? Kind regards, Matthias van de Meent Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: