Re: [pgsql-advocacy] Unlogged vs. In-Memory - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [pgsql-advocacy] Unlogged vs. In-Memory
Date
Msg-id CA+TgmoY5th4hWe3KmWQ0CqXCRExXWQA47w3+V3Ek0t1ShPpEUQ@mail.gmail.com
Whole thread Raw
In response to Re: [pgsql-advocacy] Unlogged vs. In-Memory  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [pgsql-advocacy] Unlogged vs. In-Memory
List pgsql-hackers
On Fri, Sep 23, 2011 at 10:54 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> CREATE TABLESPACE now_you_see_me_now_you_dont LOCATION
> '/mnt/highly_reliable_san' VOLATILE LOCATION '/mnt/ramdisk';
>
> All forks of temporary relations, and all non-_init forks of
> non-temporary relations, could be stored in the VOLATILE LOCATION,
> while everything else could be stored in the regular LOCATION.
>
> Hmm... actually, I kind of like that.  Thoughts?

Gah.  I mean, all forks of temporary relations, and all non-_init
forks of *unlogged* relations, could be stored in the VOLATILE
LOCATION.  Permanent tables would have all forks in the regular
LOCATION, along with _init forks of unlogged tables.

Of course, that would have the problem that relpathbackend() would
need to know the relpersistence value in order to compute the
pathname, which I think is going to be ugly, come to think of it.

Hmm...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [pgsql-advocacy] Unlogged vs. In-Memory
Next
From: Robert Haas
Date:
Subject: Re: DECLARE CURSOR must not contain data-modifying statements in WITH