On 05/09/2014 11:44 PM, Tom Lane wrote:
Greg Stark <st...@mit.edu> writes:
Well the question seems to me to be that if we're always doing recheck
then what advantage is there to not hashing everything?
Right now, there's not much. But it seems likely to me that there will be
more JSON operators in future, and some of them might be able to make use
of the additional specificity of unhashed entries. For example, it's only
a very arbitrary definitional choice for the exists operator (ie, not
looking into sub-objects) that makes jsonb_ops lossy for it. We might
eventually build a recursive-exists-check operator for which the index
could be lossless, at least up to the string length where we start to
hash.
Back to the naming:
The main difference between the two opclasses from a user's standpoint
is not whether they hash or not. The big difference is that one indexes
complete paths from the root, and the other indexes just the "leaf"
level. For example, if you have an object like '{"foo": {"bar": 123 }
}', one will index "foo", "foo->bar", and "foo->bar->123" while the
other will index "foo", "bar" and "123".
Whether the opclasses use hashing to shorten the key is an orthogonal
property, and IMHO not as important. To reflect that, I suggest that we
name the opclasses:
json_path_ops
json_value_ops
or something along those lines.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
