Re: NOLOGGING option, or ?

Поиск
Список
Период
Сортировка
От Dawid Kuroczko
Тема Re: NOLOGGING option, or ?
Дата
Msg-id 758d5e7f050601074371de6390@mail.gmail.com
обсуждение исходный текст
Ответ на Re: NOLOGGING option, or ?  (Hans-Jürgen Schönig <postgres@cybertec.at>)
Список pgsql-hackers
On 6/1/05, Hans-Jürgen Schönig <postgres@cybertec.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Google's Summer of Code ...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: fdatasync failed, I/O error