On Mon, Oct 05, 2020 at 05:46:27PM +0900, Michael Paquier wrote: > On Sat, Sep 26, 2020 at 02:56:55PM -0500, Justin Pryzby wrote: > > Also, if a partitioned index is clustered, when we clear indisclustered for > > other indexes, should we also propogate that to their parent indexes, if > > any ? > > I am not sure what you mean here. Each partition's cluster runs in > its own individual transaction based on the patch you sent. Are you > suggesting to update indisclustered for the partitioned index of a > partitioned table and all its parent partitioned in the same > transaction, aka a transaction working on the partitioned table?
No, I mean that if a partition is no longer clustered on some index, then its parent isn't clustered on that indexes parent, either. It means that we might do N catalog updates for a partition heirarchy that's N levels deep. Normally, N=2, and we'd clear indisclustered for the index as well as its parent. This is not essential, though. > >> It would be good also to check if > >> we have a partition index tree that maps partially with a partition > >> table tree (aka no all table partitions have a partition index), where > >> these don't get clustered because there is no index to work on. > > > > This should not happen, since a incomplete partitioned index is "invalid". > > Indeed, I did not know this property. I think that's something we can apply for CIC/DIC, too. It's not essential to avoid leaving an "invalid" or partial index if interrupted. It's only essential that a partial, partitioned index is not "valid". For DROP IND CONCURRENTLY, I wrote: On Mon, Sep 14, 2020 at 09:31:03AM -0500, Justin Pryzby wrote: > 2. Maybe the easiest way is to mark all indexes invalid and then drop all > partitions (concurrently) and then the partitioned parent. If interrupted, > this would leave a parent index marked "invalid", and some child tables with > no > indexes. I think this may be "ok". The same thing is possible if a > concurrent > build is interrupted, right ? -- Justin
