回复:回复:回复:how to create index concurrently on partitioned table - Mailing list pgsql-hackers

From 李杰(慎追)
Subject 回复:回复:回复:how to create index concurrently on partitioned table
Date
Msg-id f1224993-2db9-48af-b3e7-5676942394b1.adger.lj@alibaba-inc.com
Whole thread Raw
In response to Re: how to create index concurrently on partitioned table  (Michael Paquier <michael@paquier.xyz>)
Responses Re: 回复:回复:回复:how to create index concurrently on partitioned table  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: language cleanups in code and docs
Next
From: Robert Haas
Date:
Subject: Re: global barrier & atomics in signal handlers (Re: Atomicoperations within spinlocks)