| 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 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Murtagh | 2005-05-10 01:07:40 | Re: Trigger that spawns forked process |
| Previous Message | Ragnar Hafstað | 2005-05-09 23:34:40 | Re: backup compress...blobs/insert commands/verbose |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matt Olson | 2005-05-10 02:10:26 | Prefetch |
| Previous Message | David Roussel | 2005-05-09 22:38:47 | Re: "Hash index" vs. "b-tree index" (PostgreSQL 8.0) |