Re: Unlogged vs. In-Memory

On Thu, May 5, 2011 at 2:41 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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.

Well, I certainly like it when other people improve my features. But
I simply don't agree that nobody wants the current behavior. For
example, Alvaro suggested that it might be useful to sometimes have
the _init fork contain actual data, rather than being empty. That
seems problematic for a number of reasons, but certainly if we did it,
then I think it would be problematic to say that the main fork is
always under $PGDATA; that would essentially be denying people the
ability to pick which tablespace that data gets stored in. On the
other hand, if we decide that we aren't going to go that direction,
then maybe it's sensible, since you're talking about at most 8K and 1
inode per relation. But that's a discussion we should be having on
-hackers, not -advocacy....

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company