From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Kenneth Marshall <ktm(at)rice(dot)edu>, Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Preventing index scans for non-recoverable index AMs |
Date: | 2008-12-18 06:29:58 |
Message-ID: | 4949EDE6.8030500@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis wrote:
> On Wed, 2008-12-17 at 17:10 -0600, Kenneth Marshall wrote:
>> On Wed, Dec 17, 2008 at 06:07:41PM -0500, Jaime Casanova wrote:
>>> On Wed, Dec 17, 2008 at 5:47 PM, Kenneth Marshall <ktm(at)rice(dot)edu> wrote:
>>>> Rebuilding a hash index for the case
>>>> for which it is preferred (large, large tables) would be excrutiating.
>>>>
>>> there's such a situation?
>>>
>> As of 8.4, yes.
>
> My understanding was that the hash index type never supported
> recoverability, and could require a rebuild on power failure.
Right, this is certainly not a new problem. It's not even a new problem
in the context of replication or hot standby, because we already have
the problem with PITR and file-based log shipping.
Also, it's not just a problem *during* the recovery. The index is just
as corrupt after the recovery has finished.
I think we should just leave it alone for 8.4, and fix it properly in a
future relase by implementing WAL-logging for hash indexes.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Nikhil Sontakke | 2008-12-18 06:48:39 | Re: Partitioning wiki page |
Previous Message | Lawrence, Ramon | 2008-12-18 05:39:16 | Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets |