Re: tablespace + RAM disk?

Поиск
Список
Период
Сортировка
От Dawid Kuroczko
Тема Re: tablespace + RAM disk?
Дата
Msg-id 758d5e7f04112001361e517820@mail.gmail.com
обсуждение исходный текст
Ответ на Re: tablespace + RAM disk?  ("David Parker" <dparker@tazznetworks.com>)
Ответы Re: tablespace + RAM disk?
Список pgsql-performance
On Fri, 19 Nov 2004 23:18:51 -0500, David Parker
<dparker@tazznetworks.com> wrote:
> But, I'm also still interested in the answer to my question: is there
> any reason you could not put an 8.0 tablespace on a RAM disk?
>
> I can imagine doing it by having an initdb run at startup somehow, with
> the idea that having a mix of tablespaces in a database would make this
> harder, but I haven't read enough about tablespaces yet. The problem
> with trying to mix a RAM tablespace with a persistent tablespace would
> seem to be that you would have to recreate select data files at system
> startup before you could start the database. That's why an initdb seems
> cleaner to me, but...I should stop talking and go read about tablespaces
> and memcached.

I think there might be a problem with recovery after crash.  I haven't tested
it but I guess pgsql would complain that databases which existed before
crash (or even server reboot) no longer exist.  And I see two options, either
it would complain loudly and continue, or simply fail...  Unless there would
be option to mark database/schema/table as non-PITR-logged (since data
is expendable and can be easily recreated)... :)

Having tablespaces on RAM disks (like tmpfs), hmm, it could be useful,
say to put TEMPORARY tables there.  Since they will be gone nonetheless,
its a nice place for them.

Side question: Do TEMPORARY tables operations end up in PITR log?

   Regards,
       Dawid

PS: To pgmemchache I go!

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: help needed -- sequential scan problem
Следующее
От: Markus Schaber
Дата:
Сообщение: Index usage for sorted query