From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpng2.m.smailru.net (smtpng2.m.smailru.net [94.100.179.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 0A632469710 for ; Sat, 21 Nov 2020 02:26:57 +0300 (MSK) References: <20201114172823.8217-1-sergepetrenko@tarantool.org> <20201114172823.8217-3-sergepetrenko@tarantool.org> From: Vladislav Shpilevoy Message-ID: <5689a42c-1207-2259-9dca-c290ccce0849@tarantool.org> Date: Sat, 21 Nov 2020 00:26:55 +0100 MIME-Version: 1.0 In-Reply-To: <20201114172823.8217-3-sergepetrenko@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Tarantool-patches] [PATCH 2/2] box: use tuple_field_raw_by_part where possible List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Petrenko , korablev@tarantool.org Cc: tarantool-patches@dev.tarantool.org Thanks for the patch! On 14.11.2020 18:28, Serge Petrenko wrote: > tuple_field_raw_by_part allows to use part's offset slot cache to bypass > tuple field lookup in a JSON tree, which is involved even for plain > tuples. I am not sure I understand. How does it work in 1.10 then? It uses tuple_field_by_part_raw, which in the end simply calls tuple_field_raw(format, data, field_map, part->fieldno); Exactly what we had here. Why did anything change? > Since both tuple_field_raw_by_part and tuple_field_raw are basically > aliases to tuple_field_raw_by_path, prefer the former to the latter, > since it takes advantage over key part's offset slot cache. Besides, I can't find any info why do we need this 'offset slot cache'. The comment above this member simply narrates the code, and I don't understand the actual reason it was added. Did you manage to realize it? Can you explain, please?