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
