Re: doubts
От | Bo Victor Thomsen |
---|---|
Тема | Re: doubts |
Дата | |
Msg-id | ccf901c2-c0ce-496c-0fc7-4b0d663c7f8f@gmail.com обсуждение исходный текст |
Ответ на | Re: doubts (Scott Ribe <scott_ribe@elevated-dev.com>) |
Список | pgsql-admin |
Sorry for being "Captain Obvious" - If you use this method, just remember to have the necessary storage capacity available for two versions of the table in question. Med venlig hilsen / Kind regards Bo Victor Thomsen Den 04-08-2022 kl. 01:18 skrev Scott Ribe: > On Aug 3, 2022, at 5:06 PM, Thomaz Luiz Santos <thomaz.santos@gmail.com> wrote: >> I have one question: is it possible to minimize the downtime for this process ( because this table is large. ), usinganother strategy, like one view and updating the view ? > Yes, using a view and redefining it after the new data is loaded would work. You could also: > > - load new data into a new table > - begin transaction > - drop old table > - rename new table > - commit > > The drop/rename dance executes very quickly because it's just manipulating catalog entries--with the caveat that droppingthe table requires an exclusive lock for the obvious reason, so if you have a long-running transaction using thattable, you can wind up waiting for it. > > Look at the docs for CREATE TABLE and the "LIKE" option, which gives you a shortcut to creating a table with the structureof an existing one. > > One peculiarity you might or might not care about: when you create your indexes on the new table, they will be named basedon that table's name, and when you rename it the indexes don't get renamed. Personally, I am OK with "my_table_temp_some_idx"on "my_table", but if this offends your sensibilities, you can always rename the indexes ;-) andconstraints ;-) > > > >
В списке pgsql-admin по дате отправления: