Re: Unlogged tables, persistent kind

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unlogged tables, persistent kind
Date: 2011-04-25 07:14:16
Message-ID: 7E068A07-31F6-481F-9F23-8F6C9BA190D8@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Apr 24, 2011, at 1:22 PM, Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
> Unlogged tables are a good new feature.

Thanks.

> I noticed Bruce had mentioned they were the equivalent of NoSQL, which
> I don't really accept.

Me neither. I thought that was poorly said.

> Heap blocks would be zeroed if they were found to be damaged, following a crash.

The problem is not so much the blocks that are damaged (e.g. half-written, torn page) but the ones that were never written at all. For example, read page A, read page B, update tuple on page A putting new version on page B, write one but not both of A and B out to the O/S, crash. Everything on disk is a valid page, but they are not coherent taken as a whole. It's normally XLOG replay that fixes this type of situation...

I thought about this problem a bit and I think you could perhaps deal with it by having some sort of partially logged table, where we would XLOG just enough to know which blocks or relations had been modified and only nuke enough data to be certain of being safe. But it isn't clear that there is much use case for this, especially because I think it would give up nearly all the performance benefit.

I do think it might be useful to have an unlogged index on a logged table, somehow frobnicated so that on a crash the index is known invalid and not used until a REINDEX is performed.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Leonardo Francalanci 2011-04-25 07:36:35 Re: Unlogged tables, persistent kind
Previous Message Dan Ports 2011-04-25 03:33:08 Re: SSI non-serializable UPDATE performance