It would be perfectly reasonable to add an amisrecoverable like Simon
described. It could automatically set indisvalid to false after a
crash and treat the index as if indisvalid is false during recovery.
That would be a lot smoother and safer than what we have now.
It might even be possible to do this with a new wal record type so it
only happens if there was a write to the index. I imagine most users
who read that warning and use hash indexes anyways are using them on
read-only tables where they know it's safe.
--
Greg
On 18 Dec 2008, at 07:51, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com
> wrote:
Pavan Deolasee wrote:
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 ?
That has been considered many times, see archives. I believe the
changes done in 8.4 actually made it faster for some cases. And as
Kenneth pointed out hash indexes can handle keys larger than 1/3 of
page size, that b-tree can't.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
