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

On Fri, Sep 23, 2011 at 11:36 AM, Thom Brown <thom@linux.com> wrote:
> 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,

Basically, for every unlogged table, you get an empty _init fork, and
for every index of an unlogged table, you get an _init fork
initialized to an empty index.  The _init forks are copied over the
main forks by the startup process before entering normal running.

> 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.

Well, we could certainly Decree From On High that the _init forks are
all going to be stored under $PGDATA rather than in the tablespace
directories.  That would make things simple.  Of course, it also means
that if you want the _init forks stored somewhere, you are out of
luck.  Now maybe that is an unlikely scenario.  Off the top of my
head, the only case I can think of would be if the storage space or
inode consumption requirements were problematic - and even then you
could stick a symlink in there someplace to make it work, if you're
the sort of person who knows how to do that.  So maybe it's OK.  But
it makes me a little uneasy.  When people ask to put stuff in a
tablespace, I tend to think they want it to show up in that
tablespace.

Hmm, hmm...

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