Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group