Re: [HACKERS] GSoC on WAL-logging hash indexes
От | Peter Geoghegan |
---|---|
Тема | Re: [HACKERS] GSoC on WAL-logging hash indexes |
Дата | |
Msg-id | CAM3SWZRBpAz=bZYCxvQDSGKR5OA5yEhGVOCit7AyStUtq2cBDA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC on WAL-logging hash indexes (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] GSoC on WAL-logging hash indexes
Re: [HACKERS] GSoC on WAL-logging hash indexes Re: [HACKERS] GSoC on WAL-logging hash indexes |
Список | pgsql-advocacy |
On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> As a GSoC student, I will implement WAL recovery of hash indexes using the >> other index types' WAL code as a guide. Frankly, I'm skeptical of the idea that hash indexes will ever really be useful. I realize that that's a counter-intuitive conclusion, but there are many things we could do to improve B-Tree CPU costs to make them closer to those of hash indexes, without making them any less flexible. I myself would much rather work on that, and intend to. The O(1) cost seems attractive when you consider that that only requires that we read one index page from disk to service any given index scan, but in fact B-Trees almost always only require the same. They are of course also much more flexible. The concurrency characteristics B-Trees are a lot better understood. I sincerely suggest that we forget about conventional hash table type indexes. I fear they're a lost cause. -- Peter Geoghegan
В списке pgsql-advocacy по дате отправления: