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

On 23 September 2011 15:12, Robert Haas <robertmhaas@gmail.com> wrote:
> [ moving to -hacker s]
>
> On Thu, Sep 22, 2011 at 9:26 PM, Thom Brown <thom@linux.com> wrote:
>> On 22 September 2011 17:38, Josh Berkus <josh@agliodbs.com> wrote:
>>>
>>>> So are there any plans to allow swappable drive/volatile storage
>>>> unlogged tables?
>>>
>>> Be our guest.  ;-)
>>
>> Oh it can't be that difficult.  On first glance it looks like it's a
>> case of piggy-backing mdopen and getting it to treat
>> RELPERSISTENCE_TEMP relations in the same way as it would for
>> relations during the bootstrap script (i.e. create it if it doesn't
>> exist)... then telling it not to try reading anything from the
>> relation... or something like this.  But I don't know C so...
>> *puppy-dog eyes*
>
> I don't think that's it.  It seems to me that what we really need to
> do is put the _init forks in a different directory than all the other
> forks (and then fix pg_upgrade to move them if upgrading from 9.1) -
> so the core code change is actually in relpathbackend().  The question
> is how you want to expose that to the user.  I mean, you could just
> put them in another directory under the rug, and call it good.  Users
> who know about the magic under the hood can fiddle with their mount
> points, and everyone else will be none the wiser.
>
> I'm not sure whether that's acceptable from a usability standpoint,
> however.  If you want to expose an SQL-level interface, this gets to
> be a harder problem... starting with defining what exactly that
> interface should look like.

Couldn't this come under tablespace changes then?  After all the
use-case stated would require a separate tablespace, and you could do
something like:

CREATE VOLATILE TABLESPACE drive_made_of_wax_left_in_the_sun LOCATION
'/mnt/ramdisk';

All objects then created or reassigned therein would <insert magic
stuff here>.  In theory it would be independent of UNLOGGEDness, but I
can see this would be problematic because such tables wouldn't be
allowed foreign key references to tables within a stable tablespace
and vice-versa, since the wonky tablespace could collapse any minute
and integrity with it.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company