Interface for pg_autovacuum

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Interface for pg_autovacuum
Дата
Msg-id BAC211E9-BEAC-4162-A302-23DDE884DCAB@enterprisedb.com
обсуждение исходный текст
Ответы Re: Interface for pg_autovacuum  ("Florian G. Pflug" <fgp@phlo.org>)
Список 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.nasby@enterprisedb.com
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)





В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jonah H. Harris"
Дата:
Сообщение: Re: effective_cache_size vs units
Следующее
От: Steve Atkins
Дата:
Сообщение: Re: effective_cache_size vs units