From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp55.i.mail.ru (smtp55.i.mail.ru [217.69.128.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 62392445320 for ; Mon, 13 Jul 2020 01:24:37 +0300 (MSK) Date: Sun, 12 Jul 2020 22:24:36 +0000 From: Nikita Pettik Message-ID: <20200712222436.GB13229@tarantool.org> References: <1594221263-6228-1-git-send-email-alyapunov@tarantool.org> <1594221263-6228-4-git-send-email-alyapunov@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH 03/16] tx: introduce dirty tuples List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org On 12 Jul 19:15, Vladislav Shpilevoy wrote: > I still have the same question as in the previous review: > > How are the dirty tuples going to be used? Why don't we have such a flag > for vinyl tuples? > Alexander a bit explained me how new engine is supposed to work. I believe he is going to publish sort of docs containing details soon. As I understand, one of the main goals of new engine is to avoid performance degradation in case tuple is not modified during transaction. 'dirty' tuple is a tuple which features 'story': we have to seek through changes to find the proper one (depending on existing read views etc). 'clean' tuple is a casual tuple: if we read such tuple we return immediately. > > diff --git a/src/box/tuple.h b/src/box/tuple.h > > index 9a88772..4752323 100644 > > --- a/src/box/tuple.h > > +++ b/src/box/tuple.h > > @@ -319,7 +319,13 @@ struct PACKED tuple > > /** > > * Offset to the MessagePack from the begin of the tuple. > > */ > > - uint16_t data_offset; > > + uint16_t data_offset : 15; > > + /** > > + * The tuple (if it's found in index for example) could be invisible > > + * for current transactions. The flag means that the tuple must > > + * be clarified by transaction engine. > > What is current transaction? Assume, we can yield now. And there are > some transactions. A new transaction appears and adds a tuple to an index. > Will be it be visible for newer transactions? Since they are not 'current' > in terms of when the tuple was added. Or will it be visible to this > transaction only? > > > + */ > > + bool is_dirty : 1; > > /** > > * Engine specific fields and offsets array concatenated > > * with MessagePack fields array. > > @@ -1081,8 +1087,10 @@ tuple_unref(struct tuple *tuple) > > assert(tuple->refs - 1 >= 0); > > if (unlikely(tuple->is_bigref)) > > tuple_unref_slow(tuple); > > - else if (--tuple->refs == 0) > > + else if (--tuple->refs == 0) { > > + assert(!tuple->is_dirty); > > Why? Is something supposed to clear this flag after it is set? > > > tuple_delete(tuple); > > + } > > }