On Wed, Aug 11, 2021 at 10:54 AM Robert Haas <robertmh...@gmail.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
