On Sat, Sep 24, 2016 at 10:33:01AM +0530, Amit Kapila wrote: > On Sat, Sep 24, 2016 at 1:02 AM, Robert Haas <robertmh...@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?
Yes, pg_upgrade will mark the indexes as invalid and supply a script to reindex them. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
