Re: Preventing index scans for non-recoverable index AMs

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

In response to

Responses

Browse pgsql-hackers by date

  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