Re: unlogged tables

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Matheus de Oliveira <matioli(dot)matheus(at)gmail(dot)com>
Cc: dgabriel <gabriel(dot)dodan(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: unlogged tables
Date: 2015-04-13 20:49:16
Message-ID: CAKFQuwYtdCF1BFx7pji78tshjUD-oVCoOOnBcr935_tq5gY-Ag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Monday, April 13, 2015, Matheus de Oliveira <matioli(dot)matheus(at)gmail(dot)com>
wrote:

>
> On Mon, Apr 13, 2015 at 4:31 PM, dgabriel <gabriel(dot)dodan(at)gmail(dot)com
> <javascript:_e(%7B%7D,'cvml','gabriel(dot)dodan(at)gmail(dot)com');>> wrote:
>
>> "In the event of a normal shutdown, we can flush all the writes to disk
>> so we know all the data has been written, so there is no need to
>> truncate."
>>
>> Isn't possible to periodically flush data to disk and in case of crush
>> postgres to load only the data that existed at last flush? The periodic
>> flush could be configurable, for example every 30 minutes or after x rows
>> updated/inserted.
>>
>
> There is no such facility implemented for UNLOGGED TABLEs. That could be a
> feature request though.
>
>
Well, that is half right anyway. UNLOGGED tables obey checkpoints just
like any other table. The missing feature is an option to leaved restored
the last checkpoint. Instead, not knowing whether there were changes since
the last checkpoint, the system truncated the relation.

What use case is there for a behavior that the last checkpoint data is left
on the relation upon restarting - not knowing whether it was possible the
other data could have been written subsequent?

David J.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jim Nasby 2015-04-13 20:58:43 Re: unlogged tables
Previous Message Matheus de Oliveira 2015-04-13 20:40:33 Re: unlogged tables