Re:
От | Vincenzo Romano |
---|---|
Тема | Re: |
Дата | |
Msg-id | CAHjZ2x73mCMdqi4noPErHiFj2H4-vdoCU-fRYCfwWFHnhG4fnA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: (Luca Ferrari <fluca1978@infinito.it>) |
Список | pgsql-general |
2013/7/15 Luca Ferrari <fluca1978@infinito.it>: > On Mon, Jul 15, 2013 at 8:33 AM, Vincenzo Romano > <vincenzo.romano@notorand.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.
В списке pgsql-general по дате отправления: