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