Re: [HACKERS] PG10 Crash-safe and replicable Hash Indexes and UNIQUE
От | Chapman Flack |
---|---|
Тема | Re: [HACKERS] PG10 Crash-safe and replicable Hash Indexes and UNIQUE |
Дата | |
Msg-id | 7134de83-59a7-bf28-06a1-28f4523075d1@anastigmatix.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] PG10 Crash-safe and replicable Hash Indexes and UNIQUE (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] PG10 Crash-safe and replicable Hash Indexes and UNIQUE
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: