From: | "Jim Nasby" <jim(dot)nasby(at)enterprisedb(dot)com> |
---|---|
To: | "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Interface for pg_autovacuum |
Date: | 2006-12-20 06:05:30 |
Message-ID: | BAC211E9-BEAC-4162-A302-23DDE884DCAB@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I'm teaching a class this week and a student asked me about OIDs. He
related the story of how in Sybase, if you moved a database from one
server from another, permissions got all screwed up because user IDs
no longer matched. I explained that exposing something like an
integer ID in a user interface or an API is just a bad idea and
PostgreSQL doesn't do that.
Then I got to pg_autovacuum....
So... is there any reason there isn't a prescribed interface to
pg_autovacuum that doesn't expose vacrelid? Can we get that added to
TODO?
Also, in the meantime, it would make things a lot easier if the
fields in pg_autovacuum had appropriate defaults... vacrelid should
stay as-is with no default, enabled should default to true, and the
remaining fields should default to -1 so they use the system settings.
Also, I don't see a TODO about dumping pg_autovacuum; it seems that
should be added. Of course, we wouldn't want to just dump the table
itself since vacrelid would become invalid, but once there is a means
to alter vacuum settings for a table by name presumably it should be
relatively easy to add a section to pg_dump that outputs the
appropriate code to change the settings in pg_autovacuum.
--
Jim Nasby jim(dot)nasby(at)enterprisedb(dot)com
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Atkins | 2006-12-20 06:06:21 | Re: effective_cache_size vs units |
Previous Message | Jonah H. Harris | 2006-12-20 05:50:40 | Re: effective_cache_size vs units |