From: | Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it> |
---|---|
To: | Luca Ferrari <fluca1978(at)infinito(dot)it> |
Cc: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: |
Date: | 2013-07-15 11:50:22 |
Message-ID: | CAHjZ2x73mCMdqi4noPErHiFj2H4-vdoCU-fRYCfwWFHnhG4fnA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
2013/7/15 Luca Ferrari <fluca1978(at)infinito(dot)it>:
> 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
I think the "schma trick" would just make things more complex.
The "late binding" and "binding cache" would popup anyway.
From | Date | Subject | |
---|---|---|---|
Next Message | Baldur Þór Emilsson | 2013-07-15 12:45:54 | Read data from WAL |
Previous Message | Luca Ferrari | 2013-07-15 08:44:09 | Re: |