Re: Vacuum questions...
От | Joshua D. Drake |
---|---|
Тема | Re: Vacuum questions... |
Дата | |
Msg-id | 433618AA.4050705@commandprompt.com обсуждение исходный текст |
Ответ на | Vacuum questions... ("Jim C. Nasby" <jnasby@pervasive.com>) |
Ответы |
Re: Vacuum questions...
(Hannu Krosing <hannu@skype.net>)
Re: Vacuum questions... ("Jim C. Nasby" <jnasby@pervasive.com>) |
Список | pgsql-hackers |
Jim C. Nasby wrote: >Would it be difficult to vacuum as part of a dump? The reasoning behind >this is that you have to read the table to do the dump anyway, so it >would be a good time to be able to piggy-back other operations that need >to read the entire table on top. I know vacuuming of indexes complicates >this, so it's probably not as simple as just firing off a vacuum and >copy at the same time (although that idea is probably worth testing, >since it might still be a win). > > This would be a nightmare on a large database. Think of how long it takes to dump 20 gig, now add how long it is going to take to vacuum that size of DB, now think about a 500 gig database. Actually this also probably would not gain you much in 8.1 as vacuum in theory is already dealing with itself. >When dropping a table or index, is it's space immediately released in >the FSM? > > I would have to double check but I believe you would have to vacuum to reclaim the space to the FSM because the relationship is still there just like when you delete (but not truncate). >Also, would it be possible to add some means to check the status of a >running vacuum? Even with vacuum verbose, once it starts in on a large >table you have no way to know how far along it is. > > That is an interesting thought... Perhaps a quick scan of the table to see how many dead rows there are? Then check back every n/10 ? Hmmm... I am not a C guy so I don't know if that is technically feasible (although probably possible) but it is interesting from a DBA perspective. Although that could be an issue on a large table as well I think. >Finally, if vacuum_delay is enabled, does vacuum_cost_page_miss consider >a miss as not in the database buffer, or not in the kernel buffer? I >remember discussions about trying to track IO request times to try and >determine if something came out of kernel buffers or not, but AFAIK >that's all vaporware right now... > > Good question, anyone else? Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
В списке pgsql-hackers по дате отправления: