On 05/22/2017 05:16 AM, Amit Kapila wrote: > Agreed, but even if we have any such syntax, making it work for hash > indexes is tricky, because we currently store the hash code in the > index, not the original hash index key.
That was what gave me the idea in the first place, which then I realized could be more generally useful. If I could say something like CREATE INDEX ON foo USING btree ( bar, baz ALSO quux ); so that only bar and baz are compared in insertion and search, but quux is along for the ride and available to index-only scans, then the (admittedly weird) syntax CREATE INDEX ON foo USING hash ( bar ALSO bar ); could be taken to mean that the value of bar as well as its hash is wanted in the index. I was first thinking of that to save unique-insert from running to the heap to check hash collisions, though on second thought if collisions are common enough for that to be a win, maybe the hash function's just wrong. It could still be useful for index-only scans. -Chap -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
