From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 46C1721F0E for ; Sat, 29 Dec 2018 04:01:10 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ1qPZz_tiq0 for ; Sat, 29 Dec 2018 04:01:10 -0500 (EST) Received: from smtp50.i.mail.ru (smtp50.i.mail.ru [94.100.177.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 6E1A12067B for ; Sat, 29 Dec 2018 04:01:07 -0500 (EST) Date: Sat, 29 Dec 2018 12:01:03 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 3/8] sql: remove numeric affinity Message-ID: <20181229090103.GC17043@chai> References: <58b4d75729413f02134c72886ecbc749e510a1d1.1545987214.git.korablev@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58b4d75729413f02134c72886ecbc749e510a1d1.1545987214.git.korablev@tarantool.org> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org Cc: v.shpilevoy@tarantool.org, Nikita Pettik * Nikita Pettik [18/12/28 12:36]: > The only real pitfall is implicit conversion mentioned above. > What is more, vinyl engine complicates problem since it relies > on data encoding (i.e. whether it is encoded as MP_INT or MP_FLOAT). > For instance, if we encode 1.0 as MP_FLOAT during insertion, we won't > be able to use iterators from Lua, since they implicitly change type of > 1.0 and pass it to the iterator as MP_INT. Solution to this problem is > simple: lets always attempt at encoding floats as ints if conversion > takes place without loss. This is a straightforward approach, but to > implement it we need to care about reversed (decoding) situation. I think the issue is more complicated. First of all, if SQL column type is INT, Tarantool column type should be INT, and vinyl/memtx index type should be INT. This is the first thing to do/ensure and this will remove INT data type from consideration altogether. Now, for REAL data type, Tarantool data type should be NUMBER, since in Tarantool we have no separate data type for REAL, but one should *always* use MP_FLOAT/MP_DOUBLE encoding, even for integer values within this type - to simplify and speed up comparison functions. Finally, to Vinyl. It seems it has a bug in a way that it behaves differently from memtx, and differently depending on whether the value is in memory or on disk. In other words, imagine we don't have any data on disk and bloom filters are not used. Then the value '1' searched by key '1.0' will be found. Otherwise not. I believe this should be reported as a separate bug in vinyl. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov