On 2019-Jun-07, Peter Geoghegan wrote: > On Fri, Jun 7, 2019 at 9:10 AM Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx> wrote: > > I think vacuuming for global indexes is somewhat challenging as well :-) > > Maybe not as much as for indirect indexes, that's true. > > > > In order for it to be sustainable, I think you'll want to reuse > > partition identifiers when the partitions are dropped/detached, which > > means that you need a way to ensure that index entries to those > > partitions are removed from all indexes. > > I'm not so sure about that. I see your point, but I think that you can > also make the opposite argument. That is, you can make a good case for > asynchronously cleaning up the dead entries that point to a dropped > partition (probably within VACUUM). Perhaps we should offer *both* as > options. 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.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
