Re:

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.

In response to

  • Re: at 2013-07-15 08:44:09 from Luca Ferrari

Browse pgsql-general by date

  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: