On Wed, Apr 30, 2014 at 12:54 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Wed, Apr 30, 2014 at 5:55 AM, k...@rice.edu <k...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
