From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 4 Apr 2019 20:28:44 +0300 From: Vladimir Davydov Subject: Re: [PATCH 03/13] vinyl: store tuple comparison hints in tx write set Message-ID: <20190404172844.gllh3csaqghoumqt@esperanza> References: <20190404114117.GB28969@chai> <20190404122142.qixfydydgovaivuj@esperanza> <20190404124001.GL28969@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190404124001.GL28969@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Thu, Apr 04, 2019 at 03:40:01PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [19/04/04 15:24]: > > On Thu, Apr 04, 2019 at 02:41:17PM +0300, Konstantin Osipov wrote: > > > * Vladimir Davydov [19/04/02 20:35]: > > > > This patch incorporates tuple comparison hints into the transaction > > > > write set. Now, beside a statement, each txv also stores its hint, > > > > which is used in all comparison operations. > > > > > > Actually, the more I look at this patch set the more an object > > > representing a pair (vy_key?) is called for. > > > Please consider adding it, it could be passed around by value. > > > > This could be reasonable, but I don't quite like the name vy_key, > > because in vinyl we have a different concept of keys. > > > > A few names that pop into mind: > > > > vy_kv.{stmt,val} > > vy_mem_key? Nah, it's not exactly a key. It may be a tuple, actually. Would still be confusing since we have vy_stmt_is_key() helper, which checks whether a statement is in key format. Besides, we already have vy_mem_tree_key, which is used for lookups in vy_mem_tree. Having both vy_mem_key and vy_mem_tree_key would definitely be confusing. What about vy_item or vy_entry? That would emphasize that this thing comes from some kind of a container (e.g. vy_mem_tree). We already have vy_cache_entry so I'd rather call it vy_item - it's short and unique. Other variants: vy_record vy_element (or even vy_elem) vy_entity vy_unit vy_thing :) vy_object vy_article