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

Поиск
Список
Период
Сортировка
От 李杰(慎追)
Тема 回复:回复:回复:how to create index concurrently on partitioned table
Дата
Msg-id f1224993-2db9-48af-b3e7-5676942394b1.adger.lj@alibaba-inc.com
обсуждение исходный текст
Ответ на Re: how to create index concurrently on partitioned table  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: 回复:回复:回复:how to create index concurrently on partitioned table  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
> We can refer to the implementation in the ReindexRelationConcurrently,
> in the three phases of the REINDEX CONCURRENTLY,
> all indexes of the partitions are operated one by one in each phase.
> In this way, we can maintain the consistency of the entire partitioned table index.
> After we implement CIC in this way, we can also complete reindex partitioned table index concurrently (this is not done now.)

 After careful analysis, I found that there were two choices that embarrassed me.
 Although we can handle the entire partition tree with one transaction 
 in each of the three phases of CIC, just like ordinary tables.

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?

So, which schema do you think is better?
Choose to maintain consistency in all three phases, 
or just maintain consistency in the first phase?

Thank you very much,

 Regards,  Adger




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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: language cleanups in code and docs
Следующее
От: Robert Haas
Дата:
Сообщение: Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)