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: | 42E440E3.8040106@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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.
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-07-25 01:32:19 | Re: For review: Server instrumentation patch |
Previous Message | Josh Berkus | 2005-07-25 01:19:39 | Re: [HACKERS] Enticing interns to PostgreSQL |
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2005-07-25 04:45:26 | Re: [HACKERS] Autovacuum loose ends |
Previous Message | Tom Lane | 2005-07-24 23:33:37 | Re: Regression - GNUmakefile - pg_usleep |