Re: VACUUM FULL vs dump & restore
От | Aldor |
---|---|
Тема | Re: VACUUM FULL vs dump & restore |
Дата | |
Msg-id | 4335386D.4070105@mediaroot.de обсуждение исходный текст |
Ответ на | VACUUM FULL vs dump & restore ("Ilya A. Kovalenko" <shadow@oganer.net>) |
Список | pgsql-sql |
Another way how to do it with having access to the data in the same timeis to create a new table, named a little bit differentlyand do an: insert into [table]2 select * from [table]; Then switch to the second table. Then you have to do on the first table the TRUNCATE and DROP. For getting out which table is the actual one you can create a table which holds the originate table name and the actual table name. When using plpgsql you can check the table name before building the queries and then build them with EXECUTE. Be aware that you cannot do: SELECT col1, col2 FROM gettablename('[table]'); Also be aware to switch back when you do the process again, so you dump the data from the [table]2 to [table]. For my experience this way was faster then dump-truncate-restore on the table. Regards, Aldor Ilya A. Kovalenko wrote: > Greetings, > > What advantages I lose, when using dump-truncate-restore (table > or whole DB) instead of performing VACUUM FULL ? > In both cases I have no access to data, but first is much faster > (by subjective estimate). > > Thank you, > > Ilya A. Kovalenko (mailto:shadow@oganer.net) > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org >
В списке pgsql-sql по дате отправления: