I think we can resurrect hash of JSON path strings if
will store JSON strings in a canonical form. Hash allows
to improve performance for fields which have offsets in
the both old and new formats. For the old format we will
lookup by hash, for new we will use cache slot. It allows
to avoid going down the tuple_field trees and to decode
JSON on each comparison.
It is easy to convert a path into a canonical form. For
example, you can convert each identifier in the path
to ["ident"] form.
.ident -> ["ident"]
["ident"] -> unchanged
[number] -> unchanged
With these rules we can store all paths in the same
way.
On 30/07/2018 23:19, Vladislav Shpilevoy wrote:
Thanks for the fixes! Now I have no any major remark for
the RFC and the implementation method as well.
On 30/07/2018 22:23, Kirill Shcherbatov wrote:
Actual link
https://github.com/tarantool/tarantool/blob/db468f172e642d3d830018a20e545eff77c655e3/doc/rfc/1012-json-indexes.md
I still do not clearly understand what are you talking about. You can haveYou are right. This feature won't work.
different offsets in the same path: 1) [1][2][3].field and 2)
[1][2][3]["field"].
Here 'field' has offset 10 in the first case and 11 in the second
one.
If you want to use prefix length in off.cache on comparison to walk the
tuple_field trees along with the path in key_part on mismatch of cache
versions, then you should explain more clear how do you want to use
off.cache.
Lets suppose you have a key_part with a JSON path and a trees array.
To determine into which tree you first go to find offset_slot, you
should parse first path part. Same for each next part - you should
parse it to go down the tree. So you just do not know into which
tuple_field you go until the next part of the path is parsed. And how
does tuple_field.off_cache help here?
And what will you do when you met a format which does not have
an offset for the needed field? For example, I have created an
index, inserted multiple tuples, then created another index. The
format is changed, but the old tuples have the old format that
does not have an offset to the parts of the new index.
As I said, it is not special index tree. It can describe a spaceOk, fixed.
format with tens of fields among which only one is indexed.
Index_tree is not correct name. It is tuple_field array as it is
now, where each field is just a struct tuple_field. And struct
tuple_field can contain more tuple_fields inside either as an array
(if the field type is array) or inside a tree/hash if it is map.
