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 a
>> hash index smaller than the corresponding bt
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 index smaller than the corre
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 is wide. However, if t
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. You're right that we wa
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 typlen