On Fri, Mar 3, 2017 at 11:37 AM, Peter Geoghegan <p...@bowt.ie> wrote: > Please verify my understanding of your thought process: We don't have > to freeze indexes at all, ever, so if we see index bloat as a separate > problem, we also see that there is no need to *link* index needs to > the need for freezing. XID burn rate is a very bad proxy for how > bloated an index may be. Besides, we already have a separate trigger > for the thing that *actually* matters to indexes (the vacuum threshold > stuff).
Another thing I wonder about: It would be okay to use the number of unset freeze map bits as a reasonable proxy for how much bloat is in the index the first time we vacuum. But, don't we then set the freeze map bits, losing any record of having skipped indexes? What mechanism exists that allows back-pressure to actually *build up* over many vacuum anti-wraparound cycles, so that we slowly but surely get around to actually vacuuming indexes at some point? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
