From: | Thom Brown <thom(at)linux(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Rob Wultsch <wultsch(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [pgsql-advocacy] Unlogged vs. In-Memory |
Date: | 2011-09-23 14:37:12 |
Message-ID: | CAA-aLv5Ds0k2XW+ie5kUMMsY1mOaXJdGvUjkLjb8TUimi6u09g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
On 23 September 2011 15:12, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> [ moving to -hacker s]
>
> On Thu, Sep 22, 2011 at 9:26 PM, Thom Brown <thom(at)linux(dot)com> wrote:
>> On 22 September 2011 17:38, Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-09-23 14:54:13 | Re: [pgsql-advocacy] Unlogged vs. In-Memory |
Previous Message | Robert Haas | 2011-09-23 14:12:39 | Re: [pgsql-advocacy] Unlogged vs. In-Memory |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2011-09-23 14:42:51 | Re: index-only scans |
Previous Message | Cédric Villemain | 2011-09-23 14:34:34 | Re: index-only scans |