| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: hash index concurrency |
| Date: | 2012-05-30 08:49:58 |
| Message-ID: | CA+U5nML1HcPYLOpgpJ4o+rDqSbt9qCvx_X6zHNpvQQ7p1W6XEw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 30 May 2012 04:54, Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2012-05-30 09:01:51 | Re: Bug in new buffering GiST build code |
| Previous Message | Simon Riggs | 2012-05-30 08:36:49 | Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) |