Tatsuo Ishii wrote: > When a transaction aborts, it seems a BRIN index leaves summary data > which is not valid any more. Is this an expected behavior? I guess > the answer is yes, because it does not affect correctness of a query > result, but I would like to make sure.
You're right, that is not rolled back (just like any other index type, actually). > Second question is when the wrong summary data is gone? It seems > vacuum does not help. Do I have to recreate the index (or reindex)? Yeah, that's a bit of an open problem: we don't have any mechanism to mark a block range as needing resummarization, yet. I don't have any great ideas there, TBH. Some options that were discussed but never led anywhere: 1. whenever a heap tuple is deleted that's minimum or maximum for a column, mark the index tuple as needing resummarization. One a future vacuuming pass the index would be updated. (I think this works for minmax, but I don't see how to apply it to inclusion). 2. have block ranges be resummarized randomly during vacuum. 3. Have index tuples last for only X number of transactions, marking the as needing summarization when that expires. 4. Have a user-invoked function that re-runs summarization. That way the user can implement any of the above policies, or others. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
