On Fri, May 9, 2014 at 07:04:17AM -0400, Tom Lane wrote:
> Gavin Flower <GavinFlower@archidevsys.co.nz> writes:
> > On 09/05/14 15:34, Bruce Momjian wrote:
> >> Looks good. I was thinking the jsonb_ops name could remain unchanged
> >> and the jsonb_hash_ops could be called jsonb_combo_ops as it combines
> >> the key and value into a single index entry.
>
> > If you have 'jsonb_combo_ops' - then surely 'jsonb_op' should be called
> > 'jsonb_xxx_ops', where the 'xxx' distinguishes that from
> > 'jsonb_combo_ops'? I guess, if any appropriate wording of 'xxx' was too
> > cumbersome, then it would be worse.
>
> Yeah, I'm disinclined to change the opclass names now. It's not apparent
> to me that "combo" is a better choice than "hash" for the second opclass.
Well, if we are optionally hashing json_ops for long strings, what does
jsonb_hash_ops do uniquely with hashing? Does it always hash, while
json_ops optionally hashes? Is that the distinguishing characteristic?
It seemed the _content_ of the indexed value was more important, rather
than the storage method.
Should jsonb_hash_ops do only optional hashing too for long strings?
Also, with json_ops, when you index '{"exterior" : "white", "interior":
"blue"}', if you query for {"exterior" : "blue"}, does it match and have
to be rechecked in the heap because the index doesn't know which values
go with which keys?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +