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

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL
Дата
Msg-id 427FFCD3.1010803@samurai.com
обсуждение исходный текст
Ответ на Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL  ("Jim C. Nasby" <decibel@decibel.org>)
Ответы Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL  ("Jim C. Nasby" <decibel@decibel.org>)
Список pgsql-general
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

В списке pgsql-general по дате отправления:

Предыдущее
От: Ragnar Hafstað
Дата:
Сообщение: Re: backup compress...blobs/insert commands/verbose
Следующее
От: Christopher Murtagh
Дата:
Сообщение: Re: Trigger that spawns forked process