Re: 回复:回复:回复:how to create index concurrently on partitioned table

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: 回复:回复:回复:how to create index concurrently on partitioned table
Дата
Msg-id 20200618024114.GF118592@paquier.xyz
обсуждение исходный текст
Ответ на 回复:回复:回复:how to create index concurrently on partitioned table  ("李杰(慎追)" <adger.lj@alibaba-inc.com>)
Ответы 回复:回复:回复:回复:how to create index concurrently on partitioned table  ("李杰(慎追)" <adger.lj@alibaba-inc.com>)
Re: 回复:how to create index concurrently on partitioned table  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers
On Wed, Jun 17, 2020 at 10:22:28PM +0800, 李杰(慎追) wrote:
> However, I found a problem. If there are many partitions,
> we may need to handle too many missing index entries when
> validate_index().  Especially for the first partition, the time may
> have been long and many entries are missing.  In this case, why
> don't we put the second and third phase together into a transaction
> for each partition?

Not sure I am following.  In the case of REINDEX, it seems to me that
the calls to validate_index() and index_concurrently_build() can
happen in a separate transaction for each index, as long as all the
calls to index_concurrently_swap() are grouped together in the same
transaction to make sure that index partition trees are switched
consistently when all entries are swapped from an invalid state to a
valid state, because the swapping phase is also when we attach a fresh
index to a partition tree.  See also index_concurrently_create_copy()
where we don't set parentIndexRelid for the lower call to
index_create().  It would be good of course to check that when
swapping we have the code to handle that for a lot of indexes at
once.
--
Michael

Вложения

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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Resetting spilled txn statistics in pg_stat_replication
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Review for GetWALAvailability()