Re: Unlogged tables

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: "ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Unlogged tables
Date: 2017-08-09 14:37:29
Message-ID: CAKFQuwZA7rZBk+rLWC=WsRXOWZzKnHhYv0C7AuiRGAg5VeoP0w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Aug 9, 2017 at 3:39 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> This triggers a table rewrite and makes sure that all the data gets
> WAL-logged. The cost to pay for durability.
>
> > Is there a way to get my cake and eat it too?
>
> Not completely. Making data durable will have a cost at the end, but
> you can leverage it.
>
>
​Aren't you over-playing the role of the WAL in providing durability. An
unlogged table remains intact after a clean shutdown and so is "durable" if
one considers the primary "permanence" aspect of the word.

The trade-off the OP wishes for is "lose crash-safety to gain write-once
(to the data files) performance". Seeming having this on a per-table basis
would be part of the desirability. It sounds like OP would be willing to
place the table into "read only" mode in order to ensure this - which is
something that is not presently possible. I could envision that putting an
unlogged table into read-only mode would cause the system to ensure that
the data files are fully populated and then set a flag in the catalog that
informs the crash recovery process to go ahead and omit truncating that
particular unlogged table since the data files are known to be accurate.

David J.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Stephen Frost 2017-08-09 15:12:26 Re: Unlogged tables
Previous Message Michael Paquier 2017-08-09 10:39:12 Re: Unlogged tables