Re: Another small bug (pg_autovacuum) - Mailing list pgsql-hackers

From Matthew T. O'Connor
Subject Re: Another small bug (pg_autovacuum)
Date
Msg-id 1063385968.15645.29.camel@zeutrh9
Whole thread Raw
In response to Re: Another small bug (pg_autovacuum)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Another small bug (pg_autovacuum)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2003-09-12 at 12:46, Tom Lane wrote:
> How will it act with shared tables if the stats system isn't fixed?
> We may decide that tracking shared tables correctly will have to wait
> for 7.5.

The behavior in the patch will vacuum a shared table only from
template1, and only analyze from all other databases. If the stats
system isn't fixed for 7.4, then I can easily change this to vacuum
shared tables from all databases. The real problem is that each database
will only see activity that was performed in it, so we might need to
vacuum far before pg_autovacuum is shown the required amount of activity
to do something about it.

So we would have a problem if commands that effect these tables are done
from lots of different databases.  In reality, I don't think these
tables change that much (pg_database, pg_shadow, and pg_group), and most
of commands that do effect these tables are usually done from template1.

I can hardwire in something to hedge this off like setting the threshold
for shared tables much much lower than normal thresholds.  I could also
do something more complicated and try to aggregate all the activity seen
by all the databases and when the sum exceeds the threshold then have
then perform a vacuum from template1 and analyze from all other
databases.

Thoughts?




pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: Re: Need NetBSD thread tester
Next
From: Sean Chittenden
Date:
Subject: Re: massive quotes?