Re: Simple thing to make pg_autovacuum more useful - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Simple thing to make pg_autovacuum more useful
Date
Msg-id 87odbkc568.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Simple thing to make pg_autovacuum more useful  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Simple thing to make pg_autovacuum more useful  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Simple thing to make pg_autovacuum more useful  (Magnus Hagander <magnus@hagander.net>)
Re: Simple thing to make pg_autovacuum more useful  ("Dave Page" <dpage@postgresql.org>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> You are offering what appears to be a "solution". A perfectly valid one
>> in fact. Which one is going to get done first? Which one is going to
>> provide immediate benefit? 
>
> The problem is that your "immediate benefit" is to encourage people
> to do direct manual insertions into pg_autovacuum, which is something
> that we shouldn't be encouraging, because it's not the correct long-term
> solution.  Or even short-term --- it seems reasonably likely to me that
> something could be done about building a decent API in the 8.4 cycle,
> which is the soonest we could entertain a proposal to put defaults on
> pg_autovacuum anyway.

Are you picturing adding ALTER TABLE commands to set autovacuum parameters? Or
do you mean for tools like pgadmin to control this? Because the latter could
happen even during the 8.3 cycle (though I perhaps not with pgadmin itself
which I think follows the Postgres release cycle).

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Simple thing to make pg_autovacuum more useful
Next
From: Tom Lane
Date:
Subject: Re: Simple thing to make pg_autovacuum more useful