From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | "Jeff Davis" <pgsql(at)j-davis(dot)com>, "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 12:45:20 |
Message-ID: | 2e78013d0812180445k2cf95076ke3e05b2a2a22b8fa@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 18, 2008 at 6:02 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>
> In short, don't use hash index, unless you're prepared to run REINDEX
> manually after every crash.
>
I think that should be mentioned in *bold* letters in the
documentation. The doc currently has the following: "so hash indexes
might need to be rebuilt with REINDEX after a database crash" This
isn't a strong statement. How would we handle automatic recovery where
user may not even get chance to run REINDEX before his database is
corrupted ?
Hot standby will fail miserably with hash indexes since the index
would be completely useless at the standby (but planner will
nevertheless try to use it), IMHO either hash index should not be
supported at all or should be WAL logged and properly handled in
presence of hot standby.
BTW, if there is no proven case where hash index works significantly
better than btree (that's what the doc says), why not just completely
abandon it ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-12-18 12:51:42 | Re: Preventing index scans for non-recoverable index AMs |
Previous Message | Heikki Linnakangas | 2008-12-18 12:32:03 | Re: Preventing index scans for non-recoverable index AMs |