Here is an updated patch incorporating Zdenek's review, my own observation that we should make the index tupledesc tell the truth, and some other fixes/improvements such as making backwards scans work as expected.
The main thing lacking before this could be committed, from a code standpoint, is a cleaner solution to the problem of adjusting the index tupledesc (see the ugly hack in catalog/index.c). However, that complaint is irrelevant for functionality or performance testing, so I'm throwing this back out there in hopes someone will do some... I thought a little bit about how to extend this to store both hashcode and original index key, and realized that the desire to have a truthful index tupledesc makes that a *whole* lot harder. The planner, and really even the pg_index catalog representation, assume that the visible columns of an index are one-for-one with the index keys. We can slide through with the attached patch because this is still true --- effectively we're just using a "storage type" different from the indexed column's type for hash indexes, as already works for GIST and GIN. But having two visible columns would bollix up quite a lot of stuff. So I think if we actually want to do that, we'd need to revert to the concept of cheating on the tupledesc. Aside from the various uglinesses that I was able to remove from the original patch by not having that, I'm still quite concerned that we'd find something else wrong with doing that, further down the road. So my thinking right now is that we should just test this patch as-is. If it doesn't show really horrid performance when there are lots of hash key collisions, we should forget the store-both-things idea and just go with this. regards, tom lane
binNKAVnsTxLq.bin
Description: hash-v4.patch.gz
-- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches