On Sat, Sep 24, 2016 at 1:03 AM, Amit Kapila wrote:
> On Sat, Sep 24, 2016 at 1:02 AM, Robert Haas wrote:
>> Currently, hash indexes always store the hash code in the index, but
>> not the actual Datum. It's recently been noted that this can make
On Sat, Sep 24, 2016 at 10:33:01AM +0530, Amit Kapila wrote:
> On Sat, Sep 24, 2016 at 1:02 AM, Robert Haas wrote:
> > Currently, hash indexes always store the hash code in the index, but
> > not the actual Datum. It's recently been noted that this can make a
> > hash
On Sat, Sep 24, 2016 at 1:02 AM, Robert Haas wrote:
> Currently, hash indexes always store the hash code in the index, but
> not the actual Datum. It's recently been noted that this can make a
> hash index smaller than the corresponding btree index would be if the
> column
Robert Haas writes:
> Another thought is that hash codes are 32 bits, but a Datum is 64 bits
> wide on most current platforms. So we're wasting 4 bytes per index
> tuple storing nothing.
Datum is not a concept that exists on-disk. What's stored is the 32-bit
hash value.
Currently, hash indexes always store the hash code in the index, but
not the actual Datum. It's recently been noted that this can make a
hash index smaller than the corresponding btree index would be if the
column is wide. However, if the index is being built on a fixed-width
column with a