On Sun, Oct 17, 2021 at 4:30 PM Simon Riggs <simon.ri...@enterprisedb.com> wrote: > > On Thu, 14 Oct 2021 at 16:09, Peter Geoghegan <p...@bowt.ie> wrote: > > > > On Thu, Oct 14, 2021 at 12:48 AM Simon Riggs > > <simon.ri...@enterprisedb.com> wrote: > > > The hash index tuples are 20-bytes each. If that were rounded up to > > > 8-byte alignment, then that would be 24 bytes. > > > > > > Using pageinspect, the max(live_items) on any data page (bucket or > > > overflow) is 407 items, so they can't be 24 bytes long. > > > > That's the same as an nbtree page, which confirms my suspicion. The 20 > > bytes consists of a 16 byte tuple, plus a 4 byte line pointer. The > > tuple-level alignment overhead gets you from 12 bytes to 16 bytes with > > a single int4 column. So the padding is there for the taking. > > Thank you for nudging me to review the tuple length. > > Since hash indexes never store Nulls, and the hash is always fixed > length, ISTM that we can compress the hash index entries down to > ItemPointerData (6 bytes) plus any hashes. >
Nice observation but we use INDEX_AM_RESERVED_BIT (as INDEX_MOVED_BY_SPLIT_MASK) for hash indexes, so we need to take care of that in some way. -- With Regards, Amit Kapila.
