Re: [PERFORM] [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL 8.0)

[Christopher Petrilli]

On 5/9/05, Neil Conway <[EMAIL PROTECTED]> wrote:
> I don't think we've found a case in which the hash index code
> outperforms B+-tree indexes, even for "=". The hash index code also has
> a number of additional issues: for example, it isn't WAL safe, it has
> relatively poor concurrency, and creating a hash index is significantly
> slower than creating a b+-tree index.

This being the case, is there ever ANY reason for someone to use it? 
If not, then shouldn't we consider deprecating it and eventually
removing it.  This would reduce complexity, I think.

Chris
-- 
| Christopher Petrilli
| [EMAIL PROTECTED]

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org

Re: [PERFORM] [GENERAL] "Hash index" vs. "b-tree index" (PostgreSQL 8.0)

[Neil Conway]

Ying Lu wrote:
May I know for simple "=" operation query, for "Hash index" vs. "B-tree" 
index, which can provide better performance please?
I don't think we've found a case in which the hash index code 
outperforms B+-tree indexes, even for "=". The hash index code also has 
a number of additional issues: for example, it isn't WAL safe, it has 
relatively poor concurrency, and creating a hash index is significantly 
slower than creating a b+-tree index.

-Neil
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings