Re: Status of autovacuum and the sporadic stats failures ?

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Status of autovacuum and the sporadic stats failures ?
Date: 2007-02-07 19:40:15
Message-ID: 20070207194015.GD6152@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Tom Lane wrote:
> >> We could make it cleaner by inventing a function to clear out the cached
> >> statistics within a transaction, perhaps "pg_stat_reset_snaphot()" or
> >> some such name. If anyone thinks that that would be of general
> >> usefulness, I'll see about making it happen.
>
> > I came up with the idea of storing the stat hash in a particular memory
> > context, and have a flag in pgstat.c that's reset when that context is
> > reset. So each caller can define what's the appropriate lifetime.
>
> None of your use-cases require tracking multiple sets of stats within a
> transaction, so I don't see why bother with that when we can just add a
> "flush the stats" call.

Yeah, it's the same thing (and simpler), except that you move the
responsability of resetting the memory context to pgstats instead of the
calling code.

In any case, if you were to provide a mechanism for stats flush,
autovacuum would have an use case for it, so that's a +1.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-02-07 19:45:32 Re: Status of autovacuum and the sporadic stats failures ?
Previous Message Tom Lane 2007-02-07 19:38:24 Re: Ooops ... seems we need a re-release pronto