Re: possible vacuum improvement?
От | Shridhar Daithankar |
---|---|
Тема | Re: possible vacuum improvement? |
Дата | |
Msg-id | 3D74B5C9.14868.4BF672B5@localhost обсуждение исходный текст |
Ответ на | Re: possible vacuum improvement? ("Mario Weilguni" <mweilguni@sime.com>) |
Список | pgsql-hackers |
On 3 Sep 2002 at 9:36, Mario Weilguni wrote: > That is not really practicable, one datebase has 107 tables, and making a > cron job > with 107 vacuum calls is completly out of question and very error prone > anyway. That's correct.. What are the possible alternatives? Either backend has to support something or the DBA has to script something. 1)If number of tables that need vacuum are far more than those who don't, then a simple all vacuum would do. But again sizes of individual tables will affect that judgement as well. 2)As OP suggested, if vacuum could pick up only those tables marked by bitfields, ay by an additional option like, 'vacuum analyse frequent_ones'.. this is going to need a backend change. 3)I guess scripting cron job for vacuum is one time job. If it's desparately needed, say 60 tables out of 107 require vacuum, personally I would spend some time making that script. Depends upon the requirement actually. On a sidenote, does anybody have some statistics from benchmark may be, as in what's a rule of thumb for vacuuming? I found that a vacuum every 5K-10K transactions increases the tps like anything but below 1K transactions, it's not as much effective. May be one should consider this factor as well.. ByeShridhar -- Pascal: A programming language named after a man who would turn over in his grave if he knew about it. -- Datamation, January 15, 1984
В списке pgsql-hackers по дате отправления: