From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [tarantool-patches] Re: [PATCH v3 7/7] memtx: introduce tuple compare hint References: <20190225174437.yagywystuzbl7skp@esperanza> From: Kirill Shcherbatov Message-ID: <4c97b16c-19ee-402f-f692-96dbc1cd94f6@tarantool.org> Date: Tue, 26 Feb 2019 15:10:07 +0300 MIME-Version: 1.0 In-Reply-To: <20190225174437.yagywystuzbl7skp@esperanza> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit To: tarantool-patches@freelists.org, Vladimir Davydov Cc: Alexandr Lyapunov List-ID: > See a few minor comments inline. Apart from them the patch is fine by > me, but as Kostja justifiably noted, may be it's worth enabling hints > for all data types, including floating point numbers. Then we wouldn't > need the memtx tree parametrization introduced by the previous patches. > OTOH we will probably need it anyway for multikey indexes. We really need memtx tree parametrization at least because multikey index tree has own MEMTX_TREE_COMPARE/MEMTX_TREE_COMPARE_KEY functions (that use multikey_idx). Show kshch/gh-1257-multikey-index branch for more details. >> +template >> +static uint64_t >> +key_hint_uint(const char *key, struct key_def *key_def) >> +{ >> + (void)key_def; >> + assert(key_part_is_nullable(key_def->parts) == is_nullable); >> + assert(key_def->parts->type == FIELD_TYPE_UNSIGNED || >> + key_def->parts->type == FIELD_TYPE_INTEGER); > > FIELD_TYPE_INTEGER? How can that be? I've reused it below. But ok, let's just inline it. > Should be buf[8]? Yep.