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