On Wed, Apr 30, 2014 at 12:54 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Apr 30, 2014 at 5:55 AM, ktm@rice.edu <ktm@rice.edu> wrote:
>> I do not think that CPU costs matter as much as the O(1) probe to
>> get a result value specifically for very large indexes/tables where
>> even caching the upper levels of a B-tree index would kill your
>> working set in memory. I know, I know, everyone has so much memory
>> and can just buy more... but this does matter.
>
> Have you actually investigated how little memory it takes to store the
> inner pages? It's typically less than 1% of the entire index. AFAIK,
> hash indexes are not used much in any other system. I think MySQL has
> them, and SQL Server 2014 has special in-memory hash table indexes for
> in memory tables, but that's all I can find on Google.
I thought the theoretical advantage of hash indexes wasn't that they
were smaller but that you avoided a central contention point (the
btree root).
Of course our current hash indexes have *more* not less contention
than btree but I'm pretty comfortable chalking that up to quality of
implementation rather than anything intrinsic.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
