Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
От | Michail Nikolaev |
---|---|
Тема | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
Дата | |
Msg-id | CANtu0oirtBK_g4jxtw3jehSop3b0WSQaek5Sv5OGSXwxgcHwZQ@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 |
Hello, Melanie! Sorry to interrupt you, just a quick question. > Correct, but there are changes being discussed where we would freeze > tuples during pruning as well [0], which would invalidate that > implementation detail. And, if I had to choose between improved > opportunistic freezing and improved R/CIC, I'd probably choose > improved freezing over R/CIC. Do you have any patches\threads related to that refactoring (opportunistic freezing of tuples during pruning) [0]? This may affect the idea of the current thread (latest version of it mostly in [1]) - it may be required to disable such a feature for particular relation temporary or affect horizon used for pruning (without holding xmin). Just no sure - is it reasonable to start coding right now, or wait for some prune-freeze-related patch first? [0] https://www.postgresql.org/message-id/CAAKRu_a+g2oe6aHJCbibFtNFiy2aib4E31X9QYJ_qKjxZmZQEg@mail.gmail.com [1] https://www.postgresql.org/message-id/flat/CANtu0ojRX%3DosoiXL9JJG6g6qOowXVbVYX%2BmDsN%2B2jmFVe%3DeG7w%40mail.gmail.com#a8ff53f23d0fc7edabd446b4d634e7b5
В списке pgsql-hackers по дате отправления: