Re: [HACKERS] GSoC on WAL-logging hash indexes
От | Jeff Janes |
---|---|
Тема | Re: [HACKERS] GSoC on WAL-logging hash indexes |
Дата | |
Msg-id | CAMkU=1wYbPHnsab8EnkyawYrdBtt5kcrYSnHgKamU57ZBL5zyA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC on WAL-logging hash indexes (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-advocacy |
On Wed, Apr 30, 2014 at 12:26 AM, Peter Geoghegan <pg@heroku.com> wrote:
On Mon, Mar 3, 2014 at 8:12 AM, Robert Haas <robertmhaas@gmail.com> wrote:Frankly, I'm skeptical of the idea that hash indexes will ever really
>> As a GSoC student, I will implement WAL recovery of hash indexes using the
>> other index types' WAL code as a guide.
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.
If we don't put in the work to make them useful, then they won't ever become useful.
If we do put in the effort (and it would be considerable) then I think they will be. But you may be correct that the effort required would perhaps be better used in making btree even more better. I don't think we can conclude that definitively without putting in the work to do the experiment.
One advantage of the hash indexes is that the code is simple enough for someone to actually understand it in a summer. Whether it would still be like that after WAL logging was implemented, I don't know.
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.
Not sure what you mean there. The concurrency issues of the hash index has a lot less that needs to be understand. I think I understand it pretty well (unlike B-tree), I just don't know what to with that knowledge.
I sincerely
suggest that we forget about conventional hash table type indexes. I
fear they're a lost cause.
I understand that those are the only ones worth fighting for. :)
Cheers,
Jeff
В списке pgsql-advocacy по дате отправления: