Re: doubts

From: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
To: Thomaz Luiz Santos <thomaz(dot)santos(at)gmail(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: doubts
Date: 2022-08-03 23:18:41
Message-ID: 9493A23B-213C-4479-82FD-1AAE18127655@elevated-dev.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Aug 3, 2022, at 5:06 PM, Thomaz Luiz Santos <thomaz(dot)santos(at)gmail(dot)com> wrote:
>
> I have one question: is it possible to minimize the downtime for this process ( because this table is large. ), using another 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 dropping the table requires an exclusive lock for the obvious reason, so if you have a long-running transaction using that table, 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 structure of 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 based on 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 ;-) and constraints ;-)

In response to

  • doubts at 2022-08-03 23:06:26 from Thomaz Luiz Santos

Responses

  • Re: doubts at 2022-08-04 07:27:33 from Bo Victor Thomsen

Browse pgsql-admin by date

  From Date Subject
Next Message Bo Victor Thomsen 2022-08-04 07:27:33 Re: doubts
Previous Message David G. Johnston 2022-08-03 23:12:54 Re: doubts