Re: [PERFORM] Unlogged tables - Mailing list pgsql-performance

From David G. Johnston
Subject Re: [PERFORM] Unlogged tables
Date
Msg-id CAKFQuwZA7rZBk+rLWC=WsRXOWZzKnHhYv0C7AuiRGAg5VeoP0w@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORM] Unlogged tables  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [PERFORM] Unlogged tables  (Stephen Frost <sfrost@snowman.net>)
List pgsql-performance
On Wed, Aug 9, 2017 at 3:39 AM, Michael Paquier <michael.paquier@gmail.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.

pgsql-performance by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PERFORM] Unlogged tables
Next
From: Stephen Frost
Date:
Subject: Re: [PERFORM] Unlogged tables