Re: [patch] Concurrent table reindex per-index progress reporting
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: [patch] Concurrent table reindex per-index progress reporting |
| Дата | |
| Msg-id | 20200929053050.GA7117@paquier.xyz обсуждение |
| Ответ на | Re: [patch] Concurrent table reindex per-index progress reporting (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
| Список | pgsql-hackers |
On Fri, Sep 25, 2020 at 11:32:11AM +0200, Matthias van de Meent wrote: > Updating to WAIT_1 was to set it back to whatever the state was before > we would get into the loop and start_command was called. I quite > apparently didn't take enough care to set all fields that could be > set, though, so thanks for noticing. I have been considering that, and I can see your point. Not setting the phase has the disadvantage to set it to "initializing" when starting the command tracking, even for a very short time, and that could be confusing as we state in the docs that this refers to the point where the indexes are created. So, instead, I have actually set the phase to "build" or "validate". As we are updating three times the same four fields (phase, table OID, index OID and index AM) for the concurrent creation, index build and validation, I have switched the implementation to use a multi-param update instead everywhere, and applied it down to 12. Thanks for the report, Matthias. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера