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 8B6C328DCA for ; Fri, 1 Jun 2018 08:16:48 -0400 (EDT) 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 Eu4KItz65TD6 for ; Fri, 1 Jun 2018 08:16:48 -0400 (EDT) Received: from smtp15.mail.ru (smtp15.mail.ru [94.100.176.133]) (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 C13A428DC6 for ; Fri, 1 Jun 2018 08:16:47 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH] Fix ephemeral table next rowid generation References: <20180515194943.5137-1-avkhatskevich@tarantool.org> <5410C9D6-E214-4341-8DD5-4D9986372548@tarantool.org> <95f6ed87-03fb-c0ad-76e1-3776a0714e8b@tarantool.org> <492561F3-E9AF-4CBB-AC84-811F31BBBD0D@tarantool.org> From: Alex Khatskevich Message-ID: <7ba42b74-d42b-8aa5-abb1-b2c08ae62302@tarantool.org> Date: Fri, 1 Jun 2018 15:16:45 +0300 MIME-Version: 1.0 In-Reply-To: <492561F3-E9AF-4CBB-AC84-811F31BBBD0D@tarantool.org> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US 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: "n.pettik" Cc: tarantool-patches@freelists.org > Wait, where is rowid stored now? AFAIU it is still placed in the last field. Yes. We still need the rowid to be the latest field, to make tuples unique. However we cannot get the largest rowid by callind `index_max`. That was a point. > Now I am thinking about introducing secondary index for table with rowid on the last field. > Could you take a look at code and say whether this idea feasible or not? I am absolutely against it. It is overkill, to maintain the whole index just to implement a counter. > In this case, it would be easy to fetch max value from ‘last’ field and increment it. > Anyway even if this idea fails as well, lets come up with better solution. Why you do not like saving the counter in the cursor? There is an option to maintain uint64 global counter, for all temp space rowids. Rowids would not go sequentially anymore (gaps are possible), but we would preserve the main constraint: tuples would be unique. In that case we do not have to keep extra attribute in each cursor. > PS add patches mailing list to receivers so that our conversation is available for everyone. Ouch. Done.