Re: Next Steps with Hash Indexes

On Wed, Aug 11, 2021 at 10:54 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> don't know how the present patch tries to solve that problem.) It's
> tempting to think that we should think about creating something
> altogether new instead of hacking on the existing implementation, but
> that's a lot of work and I'm not sure what specific design would be
> best.

(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. That would require faster search within
pages, in particular using abbreviated keys in the ItemId array of internal
pages [1] and interpolated search rather than pure binary search (which
should work reliably with high-entropy keys like hash values), but doing
that would speed up all btree indexes, so that much is worth doing
regardless of how hash indexes are implemented. In that scheme, the hash
index AM would just be around for backward compatibility.

[1]
https://wiki.postgresql.org/wiki/Key_normalization#Optimizations_enabled_by_key_normalization

--
John Naylor
EDB: http://www.enterprisedb.com