Re: Unlogged tables, persistent kind - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Unlogged tables, persistent kind
Date
Msg-id 7E068A07-31F6-481F-9F23-8F6C9BA190D8@gmail.com
Whole thread Raw
In response to Unlogged tables, persistent kind  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Unlogged tables, persistent kind  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Apr 24, 2011, at 1:22 PM, Simon Riggs <simon@2ndQuadrant.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
writtenat all. For example, read page A, read page B, update tuple on page A putting new version on page B, write one
butnot 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
becertain of being safe. But it isn't clear that there is much use case for this, especially because I think it would
giveup 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
indexis known invalid and not used until a REINDEX is performed. 

...Robert

pgsql-hackers by date:

Previous
From: Dan Ports
Date:
Subject: Re: SSI non-serializable UPDATE performance
Next
From: Leonardo Francalanci
Date:
Subject: Re: Unlogged tables, persistent kind