Re: unlogged tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: unlogged tables
Date: 2010-12-08 19:24:34
Message-ID: AANLkTikLLQWtUTBN_cgNGxBpdof18MnLJAad4YYMfJ4M@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 8, 2010 at 1:37 PM, Chris Browne <cbbrowne(at)acm(dot)org> wrote:
> tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
>> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>>> Note that DB2 uses the table modifier VOLATILE to indicate a
>>>>> table that has a widely fluctuating table size, for example a
>>>>> queue table.
>>
>>>> the fact that DB2 uses that word to mean something entirely
>>>> different is certainly a bit awkward
>>
>>> It would be especially awkward should someone port their DB2
>>> database to PostgreSQL without noticing the semantic difference, and
>>> then find their data missing.
>>
>> Not to mention that DB2 syntax tends to appear in the standard a few
>> years later.
>
> And the term "volatile" has well-understood connotations that are
> analagous to those in DB2 in the C language and various descendants.
> <http://en.wikipedia.org/wiki/Volatile_variable>
>
> I'm not sure "UNLOGGED" is perfect... If "TEMPORARY" weren't already
> taken, it would be pretty good.
>
> Other possibilities include TRANSIENT, EPHEMERAL, TRANSIENT, TENUOUS.
>
> FLASH would be an amusing choice.  "PostgreSQL 9.1, now with support for
> FLASH!"

The value of VOLATILE, I felt, was that it's sort of like a volatile
variable in C: it might suddenly change under you. I think that
TRANSIENT and EPHEMERAL and TENUOUS all imply that the table itself is
either temporary or, in the last case, not very dense, which isn't
really what we want to convey. I did consider EPHEMERAL myself, but
the more I think about it, the more wrong it sounds. Even the table's
contents are not really short-lived - they may easily last for months
or years. You just shouldn't rely on it. I cracked up this morning
imagining calling this CREATE UNRELIABLE TABLE, but I'm starting to
think UNLOGGED is as well as we're going to do.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-12-08 19:25:57 Re: [COMMITTERS] pgsql: Optimize commit_siblings in two ways to improve group commit.
Previous Message Tom Lane 2010-12-08 19:22:22 Re: serializable read only deferrable