Re: NOLOGGING option, or ?

From: Dawid Kuroczko <qnex42(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: NOLOGGING option, or ?
Date: 2005-06-01 14:43:44
Message-ID: 758d5e7f050601074371de6390@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/1/05, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> wrote:
> Personally I don't think that it is a good idea to do that.
> People will tend to corrupt their systems because they want speed
> (sometimes without thinking about the consequences).
>
> I can only think of one scenario where nologging would actually make
> sense: Many people use session tables to keep track of user level
> information on a website. corrupting a session table (usually not very
> large) would not cause a lot of problems.

Well, from what I know, TEMPORARY tables are not WAL-logged, since
they won't exist after "restart" (since none of the current sessions
would exist). The problem with TEMPORARY tables is that they are not
globally visible.

I think it would be neat to be able to create "server-life-time" tables.
I.e. table which is initially empty, can be used by all users, but is
guaranteed to be empty (truncated) upon server restart. A place
to store global temporary variables. A table type to put on a RAM-disk.

Potential uses? Imagine a site which has a busy 'session' table and
a relatively 'static' other tables. Most of WALs would consist on
'useless' updates to session table. And recovery using WAL files
would take longer (as PostgreSQL would have to dump and restore
whole a lot of session data). Having a "global temporary" table
would be helpful in such a situation. And theoretically it wouldn't
need to "spill to disk" at all, provided it was small enough.

Regards,
Dawid

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-06-01 14:44:30 Re: fdatasync failed, I/O error
Previous Message Marc G. Fournier 2005-06-01 14:41:53 Google's Summer of Code ...