On Fri, Jun 7, 2019 at 12:18 PM Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx> wrote: > I was thinking of asynchonously cleaning it up rather than blocking > DROP/DETACH ... which means you need to keep state somewhere. I don't > think blocking DROP/DETACH is valuable -- a global index that blocks > DROP/DETACH until the index is clean serves no useful purpose. (You > could think of a multi-step approach with internal transaction commits, > similar to CIC, but you still need a plan to clean that up in case the > server crashes during that operation.) The advantage of synchronous clean-up of global indexes when DROP'ing a partition are that you can recycle the partition number (or whatever we end up calling it) immediately and predictably, and you can reuse the space in indexes occupied by keys from the dropped partition immediately and predictably. That seems less useful than asynchronous processing on average, certainly, but those are still real advantages. You seemed to be particularly concerned about quickly recycling partition numbers when we drop a partition. I hope that we can come up with a very efficient on-disk representation for global index tuples, where only the bare minimum amount of space is used for partition numbers. Maybe it won't matter that much if partition numbers cannot be recycled due to this asynchronous processing. -- Peter Geoghegan
