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
