| From: | Luca Ferrari <fluca1978(at)infinito(dot)it> |
|---|---|
| To: | Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it> |
| Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: |
| Date: | 2013-07-15 08:44:09 |
| Message-ID: | CAKoxK+6NjU9SXjQQrN4WucYUtuq7Ey53RAs6gsMzdCyfze5TbQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Jul 15, 2013 at 8:33 AM, Vincenzo Romano
<vincenzo(dot)romano(at)notorand(dot)it> wrote:
> The alternative is to do things the "good ol' way" by DELETING+INSERTING
> (http://tapoueh.org/blog/2013/07/05-archiving-data-fast.html)
> Where I'd fear for longer LOCKs.
I don't know if this is an option for your case study, but you could
also exploit schemas to achieve the result: placing the new table into
a new schema and changing the search path (disallowing access to the
old schema). Of course this means you are able to lock out your
clients during the migration or you need to use some rule to redirect
queries.
Luca
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vincenzo Romano | 2013-07-15 11:50:22 | Re: |
| Previous Message | David Welton | 2013-07-15 08:33:35 | Re: V8.4 TOAST table problem |