Re: hash index concurrency

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: hash index concurrency
Дата
Msg-id CA+U5nML1HcPYLOpgpJ4o+rDqSbt9qCvx_X6zHNpvQQ7p1W6XEw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: hash index concurrency  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: hash index concurrency  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
On 30 May 2012 04:54, Robert Haas <robertmhaas@gmail.com> wrote:

>> This was a hobby horse of mine a couple of years ago, but I never got
>> much traction.  The main question I have is, what do we even want hash
>> indexes to be?  NBTree is very good, has been extensively optimized,
>> and extensively tested.  If there is a niche left for hash indexes,
>> what is it?  Is it just very large keys which don't do well in BTrees,
>> or something else?
>
> Well, TBH, I was hoping they'd be faster than btree.

They are faster than btree in terms of response time, just not as concurrent.

Right now if you have a table bigger than RAM with direct access then
hash indexes will be faster, but I agree that the use case is not
large enough to be worth spending the time to improve hash indexes.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Bug in new buffering GiST build code