From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Simple thing to make pg_autovacuum more useful |
Date: | 2008-01-17 22:52:30 |
Message-ID: | 20080117145230.40ebb71e@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 17 Jan 2008 17:38:57 -0500
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> 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 designed to be user-friendly. The extra ease
> of use from putting defaults on that table's columns is insignificant
> compared to what we'd get by fixing its *real* problems:
>
> * superuser-only, no mechanism to let users admin their own tables
> (nor any way to reconcile user-set values with a DBA's possible
> wish to override them)
> * no support for dumping and restoring settings
>
> I don't think we should be encouraging direct manual insertions into
> pg_autovacuum in any case.
>
> So I'd rather see some effort spent on figuring out what the API
> really *should* look like. I don't know, other than that it should
> hard-wire as little as possible because we are likely to be changing
> the set of available parameters in future. Maybe we need a concept
> like per-table settings for GUC variables?
Tom I don't understand this. Your arguments above are great but let's
be realistic. I am offering something that even *I* could do with code
that is simple and useful.
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?
I can't realistically code change the code for the first problem. I
might be able to hack my way through the second, I guarantee you I
could do my solution.
So why is it such a bad thing to implement something incrementally
useful? Especially considering my incremental solution doesn't
conflict with your todo for pg_autovacuum?
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company: Since 1997, http://www.commandprompt.com/
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHj9wwATb/zqfZUUQRArj4AJ0e2ln+tul3Z7tUHMWuwSVfBC8q6ACgocP3
j5dKNnHaoClMJgJRV2mHFTA=
=j3NJ
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-17 23:10:16 | Re: [ADMIN] postgresql in FreeBSD jails: proposal |
Previous Message | Mischa Sandberg | 2008-01-17 22:52:03 | Re: [ADMIN] postgresql in FreeBSD jails: proposal |