Re: GSoC on WAL-logging hash indexes

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: GSoC on WAL-logging hash indexes
Дата
Msg-id CAM3SWZR_Xmc=ZgRJdK-JRm7OxHvCUKgdL=DVNBOs1YxOTr-1Aw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GSoC on WAL-logging hash indexes  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: GSoC on WAL-logging hash indexes  (Greg Stark <stark@mit.edu>)
Re: GSoC on WAL-logging hash indexes  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
On Wed, Apr 30, 2014 at 11:03 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> 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.

My argument doesn't hinge on there being more important work to do.
Rather, I simply don't think that there is never going to be a
compelling reason to use hash indexes in production. Apart from the
obvious inflexibility, consider what it takes to make index creation
fast - insertion-style building of indexes is much slower. Consider
multi-key indexes.

Now, I'm not telling anyone what to work on, and if someone wants to
make hash indexes WAL-logged to plug that hole, don't let me stop you.
It probably makes sense as a project to learn more about Postgres
internals. However, it would be unfair to not speak up given my
misgivings around the practical utility of hash indexes.

-- 
Peter Geoghegan



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Fix initdb for path with whitespace and at char
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Fix initdb for path with whitespace and at char