Re: Unlogged vs. In-Memory

On Thu, May 5, 2011 at 6:30 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, May 4, 2011 at 4:19 PM, Simon Riggs <simon(at)2ndquadrant(dot)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 actually think there is very little low-hanging fruit to be found in
>>> terms of improving unlogged tables.
>>
>> Solving Rob's complaint seems very easy to me.
>
> Maybe not.  I think what you're proposing would essentially amount to
> always storing the init forks in $PGDATA, even if the actual
> tablespace is elsewhere.  I agree that would solve Rob's problem, but
> I'm not sure that it's the behavior that everyone wants in general.

I doubt that anyone wants the current behaviour.

It's a very common thing for minor changes during beta to improve software.
I think we should be listening to users so that we round off the
features being delivered with a few tweaks.

No need to rush it. I'm not trying to pin anything on you, I'm trying
to improve your feature, that's all.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services