Re: [HACKERS] Autovacuum loose ends
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] Autovacuum loose ends |
Дата | |
Msg-id | 20050727202614.GE1832@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] Autovacuum loose ends (Christopher Kings-Lynne <chriskl@familyhealth.com.au>) |
Ответы |
Re: [HACKERS] Autovacuum loose ends
|
Список | pgsql-patches |
On Mon, Jul 25, 2005 at 09:31:15AM +0800, Christopher Kings-Lynne wrote: > >> We have to consider what > >> happens at stat reset -- AFAICS there's no problem, because as soon as > >> the table sees some activity, it will be picked up by pgstat. > >> However, it would be bad if stats are reset right after some heavy > >> activity on a table. Maybe the only thing we need is documentation. > > > >What's the use-case for having the stat reset feature at all? > > I believe I was the root cause of the pg_stat_reset() function. The > idea at the time was that if you decide to do a round of index > optimisation, you want to be able to search for unused indexes and > heavily seq. scanned tables. > > If you reset the stats you have 'clean' data to work with. For > instance, you can get 24 hours of clean stats data. Ok, so there's a reason for having a manual stat-reset. However what's the rationale for cleaning stats at postmaster start? In fact I think it's actively bad because you lose any data you had before postmaster stop/crash. -- Alvaro Herrera (<alvherre[a]alvh.no-ip.org>) "I personally became interested in Linux while I was dating an English major who wouldn't know an operating system if it walked up and bit him." (Val Henson)
В списке pgsql-patches по дате отправления: