Added to TODO:
o Store per-table autovacuum settings in pg_class.reloptions.
http://archives.postgresql.org/pgsql-hackers/2007-02/msg01440.php
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00724.php
On Fri, Jan 18, 2008 at 01:07:27AM +, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Joshua D. Drake [EMAIL PROTECTED] 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
On 18/01/2008, Gregory Stark [EMAIL PROTECTED] wrote:
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
On Thursday 17 January 2008 19:17:00 Joshua D. Drake wrote:
On Thu, 17 Jan 2008 21:43:46 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
All this thread is a waste of time. We've previously agreed that
we're going to store
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Table pg_catalog.pg_autovacuum
Column | Type | Modifiers
- --+-+---
vacrelid | oid | not null
enabled | boolean | not null
vac_base_thresh | integer | not null
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 16:54:47 -0500
Tom Lane [EMAIL PROTECTED] wrote:
- -1? That way by default it will use the settings in
postgresql.conf?
Surely we're not going to force initdb for that.
I didn't realize it would take that so sure lets do
Joshua D. Drake [EMAIL PROTECTED] writes:
Can we by default set vac_cost_limit and vac_cost_delay have a DEFAULT
- -1? That way by default it will use the settings in postgresql.conf?
Surely we're not going to force initdb for that.
Secondly can we set the default for freeze_min_age to 100mil
Joshua D. Drake [EMAIL PROTECTED] writes:
Your objection is let's keep it as difficult as possible within the
existing paradigm because nobody thought pg_autovacuum could be useful
in the first place.
No, my point is that there's no value in putting band-aids on an object
that was never
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 17:38:57 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Your objection is let's keep it as difficult as possible within the
existing paradigm because nobody thought pg_autovacuum could be
Joshua D. Drake [EMAIL PROTECTED] 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 17:13:52 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
There are two things here. One having a default value 8.2 currently
doesn't
I'm not really
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
There are two things here. One having a default value 8.2 currently
doesn't
I'm not really convinced by this argument. pg_autovacuum was never
designed to be user-friendly; it is designed to be the back end storage
All this thread is a waste of time. We've previously agreed that we're
going to store autovacuum per-table settings in pg_class.reloptions.
That automatically gives it pg_dump support, and moreover it means the
user needs not set the options that he/she doesn't want to change from
defaults.
--
Alvaro Herrera [EMAIL PROTECTED] writes:
All this thread is a waste of time. We've previously agreed that we're
going to store autovacuum per-table settings in pg_class.reloptions.
I had forgotten that discussion. So the plan is for the pg_autovacuum
catalog to go away entirely, correct?
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
All this thread is a waste of time. We've previously agreed that we're
going to store autovacuum per-table settings in pg_class.reloptions.
I had forgotten that discussion. So the plan is for the pg_autovacuum
catalog to go away
Tom Lane [EMAIL PROTECTED] writes:
Joshua D. Drake [EMAIL PROTECTED] 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
Gregory Stark [EMAIL PROTECTED] writes:
Are you picturing adding ALTER TABLE commands to set autovacuum
parameters?
Well, as I said, I was trying to think of an appropriate user-visible
API, which I didn't think that pg_autovacuum itself could become.
Further downthread Alvaro points out that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 21:43:46 -0300
Alvaro Herrera [EMAIL PROTECTED] wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
All this thread is a waste of time. We've previously agreed that
we're going to store autovacuum per-table
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 17 Jan 2008 20:34:07 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Are you picturing adding ALTER TABLE commands to set autovacuum
parameters?
Well, as I said, I was trying to think of an appropriate
19 matches
Mail list logo
