Re: How overcome wait for vacuum full?
| От | Nick Urbanik |
|---|---|
| Тема | Re: How overcome wait for vacuum full? |
| Дата | |
| Msg-id | 20070515232505.GA16021@nicku.org обсуждение |
| Ответ на | Re: How overcome wait for vacuum full? (Geoff Tolley <geoff@polimetrix.com>) |
| Ответы |
Re: How overcome wait for vacuum full?
|
| Список | pgsql-admin |
Thank you Geoff, On 15/05/07 16:11 -0700, Geoff Tolley wrote: >Nick Urbanik wrote: >If you're waiting on vacuum to get around to the one table, you can run >VACUUM FULL <tablename> instead. Clearly that is what I should have done! It has reached the table now. > >Personally I've found that dropping indices (including the PK), then >vacuum full, then recreating indices can be an awful lot faster than >just leaving vacuum full to its own devices. I'll investigate this for next time. >Yes you ought to be able to reclaim disk space by the copy/drop >original/rename procedure, but that gets hard to manage if you have >triggers or foreign keys on the table in question. You might want to >use CREATE TABLE table_copy (LIKE orig_table) to preserve column >defaults if you go down that path. It seems that PostgreSQL 7.3.8 does not support create table table_name like original_table. Can you suggest a way I can create a duplicate table with the same triggers and other stuff that this table has? What is the most efficient way to copy the data? -- Nick Urbanik RHCE http://nicku.org nicku@nicku.org GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24
Вложения
В списке pgsql-admin по дате отправления: