Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Дата
Msg-id CAB7nPqSARzEpj__y7bMCu3w_YgfM9Jc=wu=wHLu6ZLkgq2OMXg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Andreas Karlsson <andreas@proxel.se>)
Ответы Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] REINDEX CONCURRENTLY 2.0  (Andreas Karlsson <andreas@proxel.se>)
Список pgsql-hackers
On Tue, Feb 14, 2017 at 11:32 AM, Andreas Karlsson <andreas@proxel.se> wrote:
> On 02/13/2017 06:31 AM, Michael Paquier wrote:
>> Er, something like that as well, no?
>> DETAIL:  CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
>
> REINDEX (VERBOSE) currently prints one such line per index, which does not
> really work for REINDEX (VERBOSE) CONCURRENTLY since it handles all indexes
> on a relation at the same time. It is not immediately obvious how this
> should work. Maybe one such detail line per table?

Hard to recall this thing in details with the time and the fact that a
relation is reindexed by processing all the indexes once at each step.
Hm... What if ReindexRelationConcurrently() actually is refactored in
such a way that it processes all the steps for each index
individually? This way you can monitor the time it takes to build
completely each index, including its . This operation would consume
more transactions but in the event of a failure the amount of things
to clean up is really reduced particularly for relations with many
indexes. This would as well reduce VERBOSE to print one line per index
rebuilt.
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Removal of deprecated views pg_user, pg_group, pg_shadow