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
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 |