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 databases
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 dropped.
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.
Additionally, in
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
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 phenomenon
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. Additionally, in 8.3devel doing anything that queries
or modifies a shared table
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
