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 of
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 8.3 (not
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 would
Alvaro Herrera alvhe...@commandprompt.com 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
On Mon, Feb 9, 2009 at 12:31 PM, Robert Haas robertmh...@gmail.com 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
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 autovacuum on in
On Mon, Feb 9, 2009 at 1:44 PM, Robert Haas robertmh...@gmail.com 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.
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
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
which
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 think
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-determined
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
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
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 check for
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
Alvaro Herrera alvhe...@commandprompt.com 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,
On Thu, Feb 5, 2009 at 3:45 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
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 behaviour was
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
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 like a
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 the
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
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 add a
Simon Riggs si...@2ndquadrant.com 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
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 foo SET
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-driven
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Thu, 2009-02-05 at 17:57 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Thu, 2009-02-05 at 17:08 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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.
On Thu, Feb 5, 2009 at 11:57 PM, Simon Riggs si...@2ndquadrant.com 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
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
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
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
On Thu, Feb 5, 2009 at 7:13 PM, Robert Haas robertmh...@gmail.com 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
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 scheduling work, we
On Fri, 2009-02-06 at 00:07 +, Greg Stark wrote:
On Thu, Feb 5, 2009 at 11:57 PM, Simon Riggs si...@2ndquadrant.com 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.
36 matches
Mail list logo
