Re: [HACKERS] Buglist
От | Matthew T. O'Connor |
---|---|
Тема | Re: [HACKERS] Buglist |
Дата | |
Msg-id | 1061568377.4943.7.camel@zeutrh9 обсуждение исходный текст |
Ответ на | Re: [HACKERS] Buglist ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>) |
Список | pgsql-general |
On Fri, 2003-08-22 at 11:17, Shridhar Daithankar wrote: > On 22 Aug 2003 at 11:03, Jan Wieck wrote: > > That's why I think it needs one more pg_stat column to count the number > > of vacuumed tuples. If one does > > > > tuples_updated + tuples_deleted - tuples_vacuumed > > > > he'll get approximately the number of tuples a regular vacuum might be > > able to reclaim. If that number is really small, no need for autovacuum > > to cause any big trouble by scanning the relation. > > > > Another way to give autovacuum some hints would be to return some number > > as commandtuples from vacuum. like the number of tuples actually > > vacuumed. That together with the new number of reltuples in pg_class > > will tell autovacuum how frequent a relation really needs scanning. > > This kind of information does not really help autovacuum. If we are talking > about modifying backend stat collection algo., so that vacuum does minimum > work, is has translate to cheaper vacuum analyze so that autovacuum can fire it > at will any time. In the best case, another resident process like stat > collector can keep cleaning the deads. I believe what Jan is talking about is knowing when to use a normal vacuum, and when to do a vacuum decent. So his proposal is working under the assumption that there would be a cheaper vacuum analyze that can be run most of the time.
В списке pgsql-general по дате отправления: