Re: WORM and Read Only Tables (v0.1)

Поиск
Список
Период
Сортировка
От Peter Childs
Тема Re: WORM and Read Only Tables (v0.1)
Дата
Msg-id a2de01dd0712110607p63128a71s863176235ed1d1a9@mail.gmail.com
обсуждение исходный текст
Ответ на WORM and Read Only Tables (v0.1)  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers


On 11/12/2007, Simon Riggs <simon@2ndquadrant.com> wrote:
Attach
------

Writing tables on one system and then moving that data to other systems
is fairly common. If we supported read-only tables then you might
consider how you would publish new versions to people.

For now, we just want to consider how we will upgrade from one release
to another without needing to unload and reload potentially many
Terabytes of data. We can't delete the old data until the new data is
successfully loaded, so we will have a huge temporary storage cost. This
could go very slowly if we use cheaper storage, plus reloading the data
means we have to re-freeze it again also.

So we need a way of attaching the old tables to the new database. We
might call this binary upgrade, or we might be slightly less ambitious
and talk about just moving the old read-only data. That's all I want to
do at this stage.

I'm mentioning this here now to see what comes out in debate, and what
others are planning to work on in this area.


This sounds like allowing new versions to read old versions file structure, Probably I guess on a tablespace by table space basis

Another advantage might be to be able to load an old pitr backup in a new version across major versions. But I'm not sure that would work.

Maybe we need a command to upgrade a tablespace to a new versions file format?

Need to be careful we don't stunt future progress by fixing file format much.

Peter Childs

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Peter Childs"
Дата:
Сообщение: Re: WORM and Read Only Tables (v0.1)
Следующее
От: Michael Akinde
Дата:
Сообщение: Re: VACUUM ANALYZE out of memory