Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Autovacuum loose ends

From: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>,"Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>,pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Autovacuum loose ends
Date: 2005-07-25 01:31:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
>>  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.


In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2005-07-25 01:32:19
Subject: Re: For review: Server instrumentation patch
Previous:From: Josh BerkusDate: 2005-07-25 01:19:39
Subject: Re: [HACKERS] Enticing interns to PostgreSQL

pgsql-patches by date

Next:From: Matthew T. O'ConnorDate: 2005-07-25 04:45:26
Subject: Re: [HACKERS] Autovacuum loose ends
Previous:From: Tom LaneDate: 2005-07-24 23:33:37
Subject: Re: Regression - GNUmakefile - pg_usleep

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group