On 23 September 2011 15:56, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 23, 2011 at 10:54 AM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
