On Mon, Feb 9, 2009 at 1:44 PM, Robert Haas wrote:
>>> AIUI, the main reason for table groups would be to define different
>>> autovacuum policies for different groups of tables. Right now, that
>>> would be pretty stupid, because there are only two possible policies:
>>> "yes" and "no".
>>
>> no
>> AIUI, the main reason for table groups would be to define different
>> autovacuum policies for different groups of tables. Right now, that
>> would be pretty stupid, because there are only two possible policies:
>> "yes" and "no".
>
> not really... the idea is to let one group to have autovacuu
On Mon, Feb 9, 2009 at 12:31 PM, Robert Haas wrote:
>>> Hopefully the grouping of tables is not purely related to AV?
>>
>> Hmm, good question. I was envisioning it only for autovacuum, but it
>> hasn't been vetted on pgsql-hackers.
>
> I think we're in danger of inventing a solution in search of
Alvaro Herrera writes:
> Josh Berkus wrote:
>> Right. What I'm saying is that if it *didn't* require a sighup, then
>> users could cronjob starting and stopping Autovac themselves.
> Hmm, I'm not sure I understand what you're suggesting. Maybe what you
> want is that we have a SQL-accesible f
>> Hopefully the grouping of tables is not purely related to AV?
>
> Hmm, good question. I was envisioning it only for autovacuum, but it
> hasn't been vetted on pgsql-hackers.
I think we're in danger of inventing a solution in search of a problem here.
AIUI, the main reason for table groups wou
Josh Berkus wrote:
>>> On the other hand, I'd been keen on a runtime suset autovaccum=on/off
>>> which we could call from a cron job or the pgadmin scheduler in
>>> order to have maintenance windows. Unless that's already becoming
>>> possible?
>>
>> autovacuum=on/off is already SIGHUP as of
Simon Riggs wrote:
>
> On Thu, 2009-02-05 at 18:54 -0300, Alvaro Herrera wrote:
> > I don't see them as conflicting; I see yours as a missing feature,
> > namely the ability to add tables to an autovacuum "group", which could
> > have settings attached. Being able to do that is the whole point o
Alvaro,
On the other hand, I'd been keen on a runtime suset autovaccum=on/off
which we could call from a cron job or the pgadmin scheduler in order to
have maintenance windows. Unless that's already becoming possible?
autovacuum=on/off is already SIGHUP as of 8.3 (not SUSET, since it makes
Ron Mayer wrote:
> Joshua D. Drake wrote:
> >> The main remaining use-case seems to me to make vacuuming work adhere
> >> to some business-determined schedule, hence maintenance windows seem
> >> like the next thing to do.
> > Also agreed.
>
> Somewhat agreed - since in many cases the business-de
Joshua D. Drake wrote:
> On Thu, 2009-02-05 at 17:08 -0500, Tom Lane wrote:
>> My feeling is that we should be trying to eliminate use-cases for
>> cron-driven vacuuming, not trying to make sure that cron-driven
>> scripts can do anything autovacuum can.
> Agreed. IMO, the user should only have to
Josh Berkus wrote:
> I can't imagine, nor have I encountered in the 3 years of consulting I
> did since Autovaccum became available, such a use case.
Ok, so due to popular demand, I'm not implementing this new GUC.
> On the other hand, I'd been keen on a runtime suset autovaccum=on/off
> whi
Simon Riggs wrote:
All I'm saying is *if* we put scheduling inside Postgres for autovacuum
*then* we should make it general purpose scheduling.
If anybody uses the argument that "we have external schedulers, so don't
put them in the database" then that argument applies equally to
scheduling au
On Fri, 2009-02-06 at 00:07 +, Greg Stark wrote:
> On Thu, Feb 5, 2009 at 11:57 PM, Simon Riggs wrote:
> >
> > Writing an application maintenance utility in PL/pgSQL is much better
> > than having to write it for all the different servers an application may
> > need to run on.
>
> Welcome to
On Thu, 2009-02-05 at 19:23 -0500, Andrew Dunstan wrote:
>
> Simon Riggs wrote:
> >> not trying to make sure that cron-driven
> >> scripts can do anything autovacuum can.
> >>
> >
> > I'm not in favour of limiting our capability to internal actions only.
> > If we add a capability for schedu
On Thu, Feb 5, 2009 at 7:13 PM, Robert Haas wrote:
> Thinking about this a little more, the biggest problem I have with
> this feature is that it makes autovacuum_enabled mean two different
> things depending on context. But maybe we should change the name of
> the reloption to "autovacuum" and h
Alvaro,
First off, with over 200 GUC variables currently active, in general we
should be looking to *eliminate* variables rather than adding them. So
my personal bar for endorsing a new GUC is set pretty high.
Now, sometimes it might make more sense to keep it enabled but have it
only check
Simon Riggs wrote:
not trying to make sure that cron-driven
scripts can do anything autovacuum can.
I'm not in favour of limiting our capability to internal actions only.
If we add a capability for scheduling work, we can easily make it
capable of scheduling many kinds of work.
Writing
>> Agreed, let's get this capability out in 8.4 and we can always adust it
>> based on user demand.
>
> Oh, I agree to limiting what we do for 8,4, but we need more later.
Thinking about this a little more, the biggest problem I have with
this feature is that it makes autovacuum_enabled mean two d
On Thu, Feb 5, 2009 at 11:57 PM, Simon Riggs wrote:
>
> Writing an application maintenance utility in PL/pgSQL is much better
> than having to write it for all the different servers an application may
> need to run on.
Welcome to the suction effect. If your scheduler is in the database
then you'r
On Thu, 2009-02-05 at 17:08 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2009-02-05 at 16:29 -0500, Tom Lane wrote:
> >> It'd make more sense to put the effort into developing
> >> better scheduling control over autovacuum, such as a concept of
> >> maintenance windows.
>
> > We need
On Thu, 2009-02-05 at 17:57 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Simon Riggs writes:
> > > On Thu, 2009-02-05 at 16:29 -0500, Tom Lane wrote:
> > >> It'd make more sense to put the effort into developing
> > >> better scheduling control over autovacuum, such as a concept of
> > >> ma
Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2009-02-05 at 16:29 -0500, Tom Lane wrote:
> >> It'd make more sense to put the effort into developing
> >> better scheduling control over autovacuum, such as a concept of
> >> maintenance windows.
>
> > We need that as well, not instead of.
>
>
On Thu, 2009-02-05 at 17:08 -0500, Tom Lane wrote:
> I disagree; adding every frammish anyone could ever think of is not
> an overall improvement to the system.
>
:)
> My feeling is that we should be trying to eliminate use-cases for
> cron-driven vacuuming, not trying to make sure that cron-dr
On Thu, 2009-02-05 at 18:54 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > On Thu, 2009-02-05 at 18:25 -0300, Alvaro Herrera wrote:
> >
> > > So you're not aware that we're doing away with pg_autovacuum for good?
> > > It's going to be replaced by reloptions, i.e.
> > > ALTER TABLE fo
Simon Riggs writes:
> On Thu, 2009-02-05 at 16:29 -0500, Tom Lane wrote:
>> It'd make more sense to put the effort into developing
>> better scheduling control over autovacuum, such as a concept of
>> maintenance windows.
> We need that as well, not instead of.
I disagree; adding every frammish
Simon Riggs wrote:
>
> On Thu, 2009-02-05 at 18:25 -0300, Alvaro Herrera wrote:
>
> > So you're not aware that we're doing away with pg_autovacuum for good?
> > It's going to be replaced by reloptions, i.e.
> > ALTER TABLE foo SET (autovacuum_enabled = false);
> >
> > Obviously there's no way to
Tom Lane wrote:
> (BTW, autovac does vacuum tables to prevent wraparound even if you try
> to tell it to skip them, right?)
Yes.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list
Alvaro Herrera escreveu:
> Hi,
>
> Right now, when autovacuum is turned on we always assume it's supposed
> to process all tables except those that have autovacuum_enabled=false.
>
> Now, sometimes it might make more sense to keep it enabled but have it
> only check for certain tables, and leave
On Thu, 2009-02-05 at 18:25 -0300, Alvaro Herrera wrote:
> So you're not aware that we're doing away with pg_autovacuum for good?
> It's going to be replaced by reloptions, i.e.
> ALTER TABLE foo SET (autovacuum_enabled = false);
>
> Obviously there's no way to add a "catchall" setting.
Seems l
On Thu, 2009-02-05 at 16:29 -0500, Tom Lane wrote:
> It'd make more sense to put the effort into developing
> better scheduling control over autovacuum, such as a concept of
> maintenance windows.
We need that as well, not instead of.
People want to be able to specify (as an example)
* autovac
Simon Riggs wrote:
>
> On Thu, 2009-02-05 at 17:45 -0300, Alvaro Herrera wrote:
>
> > For this we'd have a separate GUC parameter, as in $SUBJECT (I'm not
> > wedded to the name), and have the user set autovacuum_enabled=true via
> > reloptions to enable it.
>
> I would prefer it if that behavio
On Thu, Feb 5, 2009 at 3:45 PM, Alvaro Herrera
wrote:
> Right now, when autovacuum is turned on we always assume it's supposed
> to process all tables except those that have autovacuum_enabled=false.
>
> Now, sometimes it might make more sense to keep it enabled but have it
> only check for certai
Alvaro Herrera writes:
> Right now, when autovacuum is turned on we always assume it's supposed
> to process all tables except those that have autovacuum_enabled=false.
> Now, sometimes it might make more sense to keep it enabled but have it
> only check for certain tables, and leave the majority
On Thu, 2009-02-05 at 17:45 -0300, Alvaro Herrera wrote:
> Right now, when autovacuum is turned on we always assume it's supposed
> to process all tables except those that have autovacuum_enabled=false.
>
> Now, sometimes it might make more sense to keep it enabled but have it
> only check for c
On Thu, 2009-02-05 at 17:45 -0300, Alvaro Herrera wrote:
> Hi,
>
> Right now, when autovacuum is turned on we always assume it's supposed
> to process all tables except those that have autovacuum_enabled=false.
>
> Now, sometimes it might make more sense to keep it enabled but have it
> only chec
Hi,
Right now, when autovacuum is turned on we always assume it's supposed
to process all tables except those that have autovacuum_enabled=false.
Now, sometimes it might make more sense to keep it enabled but have it
only check for certain tables, and leave the majority of them disabled.
For this
36 matches
Mail list logo
