From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 21 Feb 2019 15:11:04 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH 07/12] vinyl: sanitize full/empty key stmt detection Message-ID: <20190221121104.r5saywdjvgooynnp@esperanza> References: <20190221111051.GG3872@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190221111051.GG3872@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Thu, Feb 21, 2019 at 02:10:51PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [19/02/21 13:31]: > > Historically, we use tuple_field_count to check whether a statement > > represents an empty key (match all) or a full key (point lookup): if > > the number of fields in a tuple is greater than or equal to the number > > of parts in a key definition, it can be used as a full key; if the > > number of fields is zero, then the statement represents an empty key. > > I don't understand the purpose of this patch yet. Well, it's just a technical debt left from the json index patch. In fact, the code may be buggy/suboptimal without this patch. E.g. tuple cache heavily relays on whether the passed statement is a full or a partial key. If it fails to detect it, it won't store a chain when it should. We used to use tuple_field_count to check whether a tuple represents a full key or not: if (tuple_field_count(tuple) >= cmp_def->part_count) /* full key */ With json indexes this isn't correct anymore, because the same field may be indexed multiple times, e.g. [2].path1 and [2].path2. Due to this, the full key check may fail for a full tuple, which is obviously wrong although a full tuple must have all key parts defined. This patch makes those check work only tuples representing keys while assuming that all tuples may be used as full keys. And it wraps it inside a pair of helper functions.