Re: Unlogged vs. In-Memory

On Tue, May 3, 2011 at 6:46 PM, Joshua Berkus <josh(at)agliodbs(dot)com> wrote:

> This has come up a couple times off-list, so I thought we should hammer it out here regarding messaging for 9.1.
>
> I was discussing the Unlogged Tables feature with an industry analyst.  He advised me fairly strongly that we should call it, or at least describe it, as "in-memory tables".  While I'm not that sanguine about renaming the feature, I'm happy to use marketing terms in descriptive text in a press release if it gets people interested.
>
> Our basic issue with the cool features in 9.1 is the elevator pitch problem.  Try to describe SSI to a reporter in 20 seconds or less.  Unlogged tables suffers from this.  "What's an unlogged table? Why is *not* having something a feature?"  "long description here ..." "nevermind, I have enough."
>
> Saying "It's like a in-memory table" is a lot more successful.  And it's using the term "in-memory" the same way a lot of other DBMSes market it, i.e. in-memory == non-durable & no disk writes.  The important thing from my perspective is that unlogged tables give us the capabilities of a lot of the "in-memory" databases ... with unlogged tables and fsync off, for example, PostgreSQL becomes a viable caching database.
>
> When doing PR, it's more important to use terms people recognize than to use terms which are perfectly accurate.  Nobody expects a news article to be perfectly accurate anyway.
>
> However, I posted this because I think that several folks in the community feel that this is going too far into the land of marketese, and I want to hash it out and get consensus before we start pitching 9.1 final.

The only reason not to do this is that they aren't actually "In
Memory". Unlogged tables can be any size and therefore scroll to disk.

Now admittedly, a very large UNLOGGED table is about as robust as a
chocolate teapot, so I do see where you're coming from.

I'm at a loss to understand why the implementation is so different
from other DBMS
http://www.dba-oracle.com/oracle_news/2005_6_10_NOLOGGING_NOARCHIVELOG_Standby_Databases_Part%201.htm

With regards to a renaming, maybe we should call them CACHE TABLES, to
indicate what they are useful for. At least that doesn't confuse
things more by implying they are just in-memory.

The problem I see is that there isn't any event that fires when the
system crashes and zeroes all the tables, so if you do use it for a
cache, you must always use check-cache-or-read-from-main-source logic
because the cache isn't refilled automatically. In fact there is no
way to tell it has crashed at all, AFAICS, except by having a 1 row
table that would be empty in case of a crash.

I agree that we probably need to rename or rework them as they stand.

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