Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] pg_autovacuum should allow NULL values

From: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>,Mark Stosberg <mark(at)summersault(dot)com>, pgsql-general(at)postgresql(dot)org,pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] pg_autovacuum should allow NULL values
Date: 2007-02-24 00:08:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
On Fri, Feb 23, 2007 at 06:47:52PM -0500, Tom Lane wrote:
> I wrote:
> > I don't find this particularly important, because we have never intended
> > direct update of catalog entries to be a primary way of interacting with
> > the system.  The current pg_autovacuum setup is a stopgap until the dust
> > has settled enough that we know what sort of long-term API we want for
> > autovacuum.
> I just had an epiphany about that.  We've wanted to avoid setting the
> autovacuum knobs in stone, because it's pretty obvious they're not
> ready, and that has prevented us from inventing any nice SQL syntax for
> managing the per-table settings.
> Meanwhile, the storage-parameter infrastructure got added in 8.2.
> Isn't that an absolutely ideal framework for managing per-table autovac
> settings?  We could drop the separate pg_autovacuum catalog altogether
> and keep all the info in pg_class.reloptions.  Advantages:
> * The infrastructure is all there already, including ALTER TABLE and
> pg_dump support.
> * The parameter names are not SQL keywords, and the syntax isn't
> hardwired to any particular set of them.  So it would be fairly painless
> to change the set of supported parameters, with or without backwards
> compatibility to keep on recognizing an old parameter.
> Disadvantages:
> * Wouldn't be forwards-compatible with any hacks that people might
> currently have to dump and restore pg_autovacuum contents.  But you
> could probably make a script to read your existing table and emit
> ALTER TABLE SET commands instead.

Actually, if we wanted to we should be able to create a view that takes
the place of the current pg_autovacuum. With appropriate rules and some
functions, you could probably even make it updatable.
Jim Nasby                                            jim(at)nasby(dot)net
EnterpriseDB      512.569.9461 (cell)

In response to

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-02-24 00:30:29
Subject: Re: SCMS question
Previous:From: Jim C. NasbyDate: 2007-02-24 00:03:09
Subject: Re: SCMS question

pgsql-general by date

Next:From: Richard Broersma JrDate: 2007-02-24 00:14:55
Subject: Re: postgresql vs mysql
Previous:From: Joshua D. DrakeDate: 2007-02-24 00:02:40
Subject: Re: Re: 5 Weeks till feature freeze or (do you know where your patch is?)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group