Re: Next Steps with Hash Indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Next Steps with Hash Indexes
Date: 2021-08-11 16:04:10
Message-ID: 4007593.1628697850@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

John Naylor <john(dot)naylor(at)enterprisedb(dot)com> writes:
> (Standard disclaimer that I'm not qualified to design index AMs) I've seen
> one mention in the literature about the possibility of simply having a
> btree index over the hash values.

Yeah, that's been talked about in the past --- we considered it
moderately seriously back when the hash AM was really only a toy
for lack of WAL support. The main knock on it is that searching
a btree is necessarily O(log N), while in principle a hash probe
could be O(1). Of course, a badly-implemented hash AM could be
worse than O(1), but we'd basically be giving up on ever getting
to O(1).

There's a separate discussion to be had about whether there should
be an easier way for users to build indexes that are btrees of
hashes. You can do it today but the indexes aren't pleasant to
use, requiring query adjustment.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2021-08-11 16:08:55 Re: Insert Documentation - Returning Clause and Order
Previous Message John Naylor 2021-08-11 15:51:00 Re: Next Steps with Hash Indexes