From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Kirill Shcherbatov Subject: Re: [tarantool-patches] Re: [PATCH v5 02/12] box: introduce key_def_parts_are_sequential References: <3924ec17fa3fca408efcc759e1f28c1b8f5fe19d.1540795996.git.kshcherbatov@tarantool.org> <20181101142320.GE30032@chai> Message-ID: Date: Tue, 6 Nov 2018 15:14:54 +0300 MIME-Version: 1.0 In-Reply-To: <20181101142320.GE30032@chai> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit To: tarantool-patches@freelists.org, Kostya Osipov Cc: Vladimir Davydov List-ID: > They still can: > Paths foo.bar[0] and foo.bar[1] refer to sequential fields. Yes, you are right. Generally it should be possible to make correct is_sequential test for JSON indexes, but - at first - such tests are not trivial and require already built JSON tree, like the format has. There are two moments that obstruct it's introducing: 1) in usage scenario tuple_extract_key_slowpath_raw that use key_def_parts_are_sequential routine doesn't operate with tuple format entity(we can get around it by doing key_def->has_json_path flag lookup) 2) in key_def prepare step key_def_new/key_def_set_cmp/tuple_extract_key_set no format object containing JSON path exists in tarantool at all. I don't like temporal JSON tree object compiled by definitions on key_def_new step to set this unlikely optimization flag.