On Thu, May 5, 2011 at 19:30, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, May 4, 2011 at 4:19 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Well, the _init fork can go arbitrarily long without being used, so
>>> you can't put any unfrozen tuples in there. There may be some game
>>> that can be played here, but it's not simple, especially since the
>>> heap and indices have to stay in sync.
>>
>> I don't think that's a sufficient response. It's clear that people
>> expect unlogged tables would be used in conjunction with RAM disks,
>> but they clearly don't work in that situation.
>>
>> That is exactly the main use case of "cache tables".
>
> I think it's a bit harsh to say that they "don't work". As I
> understand it, the use case that Rob is seeking here is the ability to
> create a table space on a RAM disk and put unlogged tables (only) into
> it and have everything continue to work after a reboot obliterates the
> contents of the RAM disk. Fair enough - I can understand why that
> would be useful, but I don't think we've ever promised anyone that
> blowing away a tablespace was a safe operation. It might actually be
> safe if only temporary tables are involved... assuming that the mount
> point was the PG_<version>_<catversion> directory, rather than the
> tablespace directory proper... but I doubt that we've ever documented
> that anywhere, or promised that it would continue working in future
> releases. It's a new idea to me, anyhow.
I don't believe we do.
However, it would in a lot of cases be very useful to have osmething
like CREATE TEMPORARY TABLESPACE <blah>. Which would only accept
temporary (and maybe unlogged) tables. And then would auto-create the
PG_<version>_<catversion> directory upon startup.
That's obviously a 9.2 feature though, it's not an adjustment of an
existing one, it's brand new :-)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
