Re: todo: Hash index creation
От | Naz Gassiep |
---|---|
Тема | Re: todo: Hash index creation |
Дата | |
Msg-id | 468862A6.4070303@mira.net обсуждение исходный текст |
Ответ на | Re: todo: Hash index creation (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: todo: Hash index creation
Re: todo: Hash index creation |
Список | pgsql-hackers |
> Actually I think the *most* important thing to work on is to get hash to > the point where its search speed actually beats btree consistently, so > that it has an excuse to live. If that is insoluble we might well end up > ripping it out entirely. (The first three TODO items for hash indexes > are ideas for trying to improve the speed.) > > Fixing the WAL support would come after that, and bring it to the point > where someone could actually recommend it for production use. > > After that it would be sensible to work on inessentials like improving > the build speed. I've been warned away from hash indexes before, however I had no idea that it's performance was that abysmal that BTREE beat it and I was definitely not aware that they were not included in WAL logs. I was told it wasn't as good as it could be, but I wasn't told it was pretty much an alpha piece of code. As a result, when creating tables containing large blocks of text I wish to index, I've been using HASH as an index method. Please can we state in the manual that HASH index types are in a beta stage of development or something similar, or perhaps remove the manual entry altogether until HASH is at a point where it is usable in production. Regards, A very surprised n00b.
В списке pgsql-hackers по дате отправления: