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
|
| Список | 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 по дате отправления: