On Sat, Sep 24, 2016 at 1:02 AM, Robert Haas <robertmhaas@gmail.com> 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 the index is being built on a fixed-width
> column with a typlen <= sizeof(Datum), we could store the original
> value in the hash index rather than the hash code without using any
> more space. That would complicate the code, but I bet it would be
> faster: we wouldn't need to set xs_recheck, we could rule out hash
> collisions without visiting the heap, and we could support index-only
> scans in such cases.
>
What exactly you mean by Datum? Is it for datatypes that fits into 64
bits like integer. I think if we are able to support index only scans
for hash indexes for some data types, that will be a huge plus.
Surely, there is some benefit without index only scans as well, which
is we can avoid recheck, but not sure if that alone can give us any
big performance boost. As, you say, it might lead to some
complication in code, but I think it is worth trying.
Won't it add some requirements for pg_upgrade as well?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
