Re: Unlogged vs. In-Memory - Mailing list pgsql-advocacy

On Tue, May 3, 2011 at 6:46 PM, Joshua Berkus <josh@agliodbs.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
callit, or at least describe it, as "in-memory tables".  While I'm not that sanguine about renaming the feature, I'm
happyto 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
secondsor 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
lotof other DBMSes market it, i.e. in-memory == non-durable & no disk writes.  The important thing from my perspective
isthat unlogged tables give us the capabilities of a lot of the "in-memory" databases ... with unlogged tables and
fsyncoff, 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.
 Nobodyexpects 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
landof 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