Re: [pgsql-advocacy] Unlogged vs. In-Memory
От | Thom Brown |
---|---|
Тема | Re: [pgsql-advocacy] Unlogged vs. In-Memory |
Дата | |
Msg-id | CAA-aLv5Ds0k2XW+ie5kUMMsY1mOaXJdGvUjkLjb8TUimi6u09g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [pgsql-advocacy] Unlogged vs. In-Memory (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [pgsql-advocacy] Unlogged vs. In-Memory
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: