Re: Simple thing to make pg_autovacuum more useful
От | Joshua D. Drake |
---|---|
Тема | Re: Simple thing to make pg_autovacuum more useful |
Дата | |
Msg-id | 20080117145230.40ebb71e@commandprompt.com обсуждение исходный текст |
Ответ на | Re: Simple thing to make pg_autovacuum more useful (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Simple thing to make pg_autovacuum more useful
|
Список | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 17 Jan 2008 17:38:57 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.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-----
В списке pgsql-hackers по дате отправления: