Re: [HACKERS] new autovacuum criterion for visible pages
От
Alvaro Herrera
Тема
Re: [HACKERS] new autovacuum criterion for visible pages
Дата
Msg-id
20170203211720.66jrfs76whpk5fji@alvherre.pgsql
Ответ на
Re: [HACKERS] new autovacuum criterion for visible pages (Stephen Frost)
Список
Дерево обсуждения
new autovacuum criterion for visible pages Jeff Janes <jeff.janes@gmail.com>
Re: new autovacuum criterion for visible pages Amit Kapila <amit.kapila16@gmail.com>
Re: new autovacuum criterion for visible pages Jeff Janes <jeff.janes@gmail.com>
Re: new autovacuum criterion for visible pages Jim Nasby <Jim.Nasby@BlueTreble.com>
Re: new autovacuum criterion for visible pages Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: new autovacuum criterion for visible pages Vik Fearing <vik@2ndquadrant.fr>
Re: new autovacuum criterion for visible pages Amit Kapila <amit.kapila16@gmail.com>
Re: new autovacuum criterion for visible pages Michael Paquier <michael.paquier@gmail.com>
Re: new autovacuum criterion for visible pages Michael Paquier <michael.paquier@gmail.com>
Re: new autovacuum criterion for visible pages Michael Paquier <michael.paquier@gmail.com>
Re: new autovacuum criterion for visible pages Tom Lane <tgl@sss.pgh.pa.us>
Re: new autovacuum criterion for visible pages Masahiko Sawada <sawada.mshk@gmail.com>
Re: new autovacuum criterion for visible pages Simon Riggs <simon@2ndquadrant.com>
Re: [HACKERS] new autovacuum criterion for visible pages Stephen Frost <sfrost@snowman.net>
Re: [HACKERS] new autovacuum criterion for visible pages Alvaro Herrera <alvherre@2ndquadrant.com>
Re: [HACKERS] new autovacuum criterion for visible pages Amit Kapila <amit.kapila16@gmail.com>
Re: [HACKERS] new autovacuum criterion for visible pages Stephen Frost <sfrost@snowman.net>
Re: [HACKERS] new autovacuum criterion for visible pages Vik Fearing <vik.fearing@2ndquadrant.com>
Re: [HACKERS] new autovacuum criterion for visible pages Jeff Janes <jeff.janes@gmail.com>
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
В списке pgsql-hackers по дате отправления
От: Robert Haas
Дата:
От: Corey Huinker
Дата: