Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > Further investigation shows that what really seems to be happening
> > in 8.3devel is that the statistics for shared tables are reset every
> > 15 seconds when autovacuum is enabled, which it is by default. I
> > don't observe this phe
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Further investigation shows that what really seems to be happening
> in 8.3devel is that the statistics for shared tables are reset every
> 15 seconds when autovacuum is enabled, which it is by default. I
> don't observe this phenomenon when autovacuum is
On Thu, Jun 07, 2007 at 11:41:56AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The attached patch fixes this.
>
> Wouldn't it be easier to just special-case the shared DB in
> pgstat_vacuum_tabstat?
Thanks; I'll test these patches when I get a chance.
> >> Additionall
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The problem is that the database hash is cleared of databases that no
> longer exist, and the database list is constructed by scanning
> pg_database. Since no entry exist for the database we use for shared
> tables (InvalidOid), the hash table is droppe
Michael Fuhr wrote:
> Is vacuuming any table supposed to zero the statistics for all
> shared tables? Doesn't that have implications for autovacuum? The
> example below is in 8.2.4 but I'm seeing similar behavior in 8.1.9
> and 8.3devel.
The problem is that the database hash is cleared of databa
Michael Fuhr wrote:
> Is vacuuming any table supposed to zero the statistics for all
> shared tables?
Huh, certainly not. In any case, I think the problem may be related to
the fact that stats for shared tables are kept in a separate hash from
regular tables.
I'll investigate the issue tomorrow
