Skip site navigation (1) Skip section navigation (2)

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

From: Neil Conway <neilc(at)samurai(dot)com>
To: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
Cc: Christopher Petrilli <petrilli(at)gmail(dot)com>,Ying Lu <ying_lu(at)cs(dot)concordia(dot)ca>, pgsql-general(at)postgresql(dot)org,pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL
Date: 2005-05-10 00:14:11
Message-ID: 427FFCD3.1010803@samurai.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-performance
Jim C. Nasby wrote:
 >> No, hash joins and hash indexes are unrelated.
> I know they are now, but does that have to be the case?

I mean, the algorithms are fundamentally unrelated. They share a bit of 
code such as the hash functions themselves, but they are really solving 
two different problems (disk based indexing with (hopefully) good 
concurrency and WAL logging vs. in-memory joins via hashing with spill 
to disk if needed).

> Like I said, I don't know the history, so I don't know why we even
> have them to begin with.

As I said, the idea of using hash indexes for better performance on 
equality scans is perfectly valid, it is just the implementation that 
needs work.

-Neil

In response to

Responses

pgsql-performance by date

Next:From: Matt OlsonDate: 2005-05-10 02:10:26
Subject: Prefetch
Previous:From: David RousselDate: 2005-05-09 22:38:47
Subject: Re: "Hash index" vs. "b-tree index" (PostgreSQL 8.0)

pgsql-general by date

Next:From: Christopher MurtaghDate: 2005-05-10 01:07:40
Subject: Re: Trigger that spawns forked process
Previous:From: Ragnar HafstaĆ°Date: 2005-05-09 23:34:40
Subject: Re: backup compress...blobs/insert commands/verbose

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group