Stephen Frost wrote: > Tracking the INSERTs as a reason to VACUUM is also very natural when you > consider the need to update BRIN indexes. I am a bit worried that if we > focus just on if the VM needs to be updated or not that we might miss > out on cases where we need to VACUUM because the BRIN indexes are out of > date.
Actually, I was thinking in a different approach for BRIN -- namely that brininsert, on its fast path out where it sees an insert on a non-summarized range, record on the index's metapage what the last inserted page is, as well as what's the latest summarized pages. When a range is complete, it saves the index OID in a DSA so that the next autovacuum worker knows to run (the equivalent of) brinsummarize on the index.(*) That's efficient because this only occurs when it is known that a range can be usefully summarized, instead of using a heuristic based on tuples inserted, which may or may not correspond to a certain number of filled pages. (*) I think it's better if this only summarizes complete ranges, leaving incomplete ones alone (which is what it does now). That way, if there's a bulk insert going, we leave it to run at full speed the whole time. -- Álvaro Herrera https://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
