From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tarantool-patches-bounce@freelists.org>
Received: from localhost (localhost [127.0.0.1])
	by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2186F25EEF
	for <tarantool-patches@freelists.org>; Tue, 19 Jun 2018 10:55:13 -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 UIEoQ5Y2MSVZ for <tarantool-patches@freelists.org>;
	Tue, 19 Jun 2018 10:55:13 -0400 (EDT)
Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103])
	(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 D57F4242BE
	for <tarantool-patches@freelists.org>; Tue, 19 Jun 2018 10:55:12 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: [tarantool-patches] Re: [PATCH] Fix ephemeral table next rowid
 generation
From: "n.pettik" <korablev@tarantool.org>
In-Reply-To: <7ba42b74-d42b-8aa5-abb1-b2c08ae62302@tarantool.org>
Date: Tue, 19 Jun 2018 17:55:10 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <DC25CF8B-C043-4A7B-AB13-CDCD4ABEE1FE@tarantool.org>
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>
 <7ba42b74-d42b-8aa5-abb1-b2c08ae62302@tarantool.org>
Sender: tarantool-patches-bounce@freelists.org
Errors-to: tarantool-patches-bounce@freelists.org
Reply-To: tarantool-patches@freelists.org
List-help: <mailto:ecartis@freelists.org?Subject=help>
List-unsubscribe: <tarantool-patches-request@freelists.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-Id: tarantool-patches <tarantool-patches.freelists.org>
List-subscribe: <tarantool-patches-request@freelists.org?Subject=subscribe>
List-owner: <mailto:>
List-post: <mailto:tarantool-patches@freelists.org>
List-archive: <http://www.freelists.org/archives/tarantool-patches>
To: tarantool-patches@freelists.org
Cc: Alex Khatskevich <avkhatskevich@tarantool.org>


>> 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.

Well, I am of the opinion that it is not overkill, but proper solution.
Lets ask smb else for advice. Personally I strictly against your =
approach.

>> In this case, it would be easy to fetch max value from =E2=80=98last=E2=
=80=99 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?

Since cursor is a kind of wrapper around iterator, i.e. it represents =
only interface of=20
internal routine. On the other hand, rowid belongs to the =E2=80=98user=E2=
=80=99 space.=20
Moreover, not all ephemeral spaces needs this rowid. Finally, if smith =
went wrong
and insertion in such space occurred not via this cursor, then rowid =
would be
Incorrect and no warning or error would appear. I would like to remind =
you that
we wanted to avoid using cursors for insertions and removals.

> There is an option to maintain uint64 global counter, for all temp =
space rowids.

Hm, once I heard that using global variables might lead you straight to =
the hell...