On 2013-09-06 01:22:36 -0400, Alvaro Herrera wrote: > I think it's shortsighted to keep thinking of autovacuum as just a way > to run VACUUM and ANALYZE. We have already discussed work items that > need to be done separately, such as truncating the last few empty pages > on a relation that was vacuumed recently. We also need to process a GIN > index' pending insertion list; and with minmax indexes I will want to > run summarization of heap page ranges.
Agreed. > So maybe instead of trying to think of VM bit setting as part of vacuum, > we could just keep stats about how many pages we might need to scan > because of possibly needing to set the bit, and then doing that in > autovacuum, independently from actually vacuuming the relation. I am not sure I understand this though. What would be the point to go and set all visible and not do the rest of the vacuuming work? I think triggering vacuuming by scanning the visibility map for the number of unset bits and use that as another trigger is a good idea. The vm should ensure we're not doing superflous work. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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
