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 D618728C32 for ; Fri, 1 Jun 2018 07:50:42 -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 kF2FwnTUvxFn for ; Fri, 1 Jun 2018 07:50:42 -0400 (EDT) Received: from smtp59.i.mail.ru (smtp59.i.mail.ru [217.69.128.39]) (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 8E37D28C2F for ; Fri, 1 Jun 2018 07:50:42 -0400 (EDT) From: "n.pettik" Message-Id: <492561F3-E9AF-4CBB-AC84-811F31BBBD0D@tarantool.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_7ED2307D-3BBB-4230-B029-87812B346BC6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: [tarantool-patches] Re: [PATCH] Fix ephemeral table next rowid generation Date: Fri, 1 Jun 2018 14:50:39 +0300 In-Reply-To: <95f6ed87-03fb-c0ad-76e1-3776a0714e8b@tarantool.org> References: <20180515194943.5137-1-avkhatskevich@tarantool.org> <5410C9D6-E214-4341-8DD5-4D9986372548@tarantool.org> <95f6ed87-03fb-c0ad-76e1-3776a0714e8b@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: Alex Khatskevich Cc: tarantool-patches@freelists.org --Apple-Mail=_7ED2307D-3BBB-4230-B029-87812B346BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> As for patch itself, I don=E2=80=99t like the idea to store rowid for = ephemeral space >> in cursor: if insertion in such space occurred not via SQL = facilities, then >> rowid would be wrong=E2=80=A6Well, we know that rowid is always in >> the last field, so why just don=E2=80=99t fetch value from last field = and increment it? > Rowid cannot be stored in the last field, because tuples are sorted by = the first parts. Wait, where is rowid stored now? AFAIU it is still placed in the last = field. > That means that means that greatest tuple may not has the greatest = rowid. 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? 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. PS add patches mailing list to receivers so that our conversation is = available for everyone. --Apple-Mail=_7ED2307D-3BBB-4230-B029-87812B346BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

As for patch itself, I = don=E2=80=99t like the idea to store rowid for ephemeral space
in cursor: if insertion in such space occurred not via SQL = facilities, then
rowid would be wrong=E2=80=A6Well, we = know that rowid is always in
the last field, so why just = don=E2=80=99t fetch value from last field and increment it?
Rowid cannot be stored in the last field, = because tuples are sorted by the first parts.

Wait, where = is rowid stored now? AFAIU it is still placed in the last = field.

That means that means that greatest tuple may = not has the greatest rowid.

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?

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.

PS add patches mailing list to receivers so that = our conversation is available for everyone.

= --Apple-Mail=_7ED2307D-3BBB-4230-B029-87812B346BC6--