Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alex Khatskevich <avkhatskevich@tarantool.org>
To: "n.pettik" <korablev@tarantool.org>
Cc: tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH] Fix ephemeral table next rowid generation
Date: Fri, 1 Jun 2018 15:16:45 +0300	[thread overview]
Message-ID: <7ba42b74-d42b-8aa5-abb1-b2c08ae62302@tarantool.org> (raw)
In-Reply-To: <492561F3-E9AF-4CBB-AC84-811F31BBBD0D@tarantool.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.

  reply	other threads:[~2018-06-01 12:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-15 19:49 [tarantool-patches] " AKhatskevich
2018-05-31 23:53 ` [tarantool-patches] " n.pettik
     [not found]   ` <95f6ed87-03fb-c0ad-76e1-3776a0714e8b@tarantool.org>
2018-06-01 11:50     ` n.pettik
2018-06-01 12:16       ` Alex Khatskevich [this message]
2018-06-19 14:55         ` n.pettik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7ba42b74-d42b-8aa5-abb1-b2c08ae62302@tarantool.org \
    --to=avkhatskevich@tarantool.org \
    --cc=korablev@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH] Fix ephemeral table next rowid generation' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox