On 23 September 2011 15:56, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
I doubt I understand the whole _init forks thing correctly, but can't
the main tablespace provide sanctuary to such volatile supporting meta
data (pg_version, _init and whatever else you're worried about) except
the actual relation (and its vm/fsm)? Anything you can't afford to
lose you get the main tablespace to look after. And instead of having
a dir linked to the location in pg_tblspc, an actual dir could exist,
containing items directly linked to items in the volatile location.
Hmm... it doesn't sound quite right to me either.
--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company