From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vdavydov.dev@gmail.com>
Date: Wed, 11 Jul 2018 10:57:36 +0300
From: Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [RFC PATCH 01/23] vinyl: do not turn REPLACE into INSERT when
 processing DML request
Message-ID: <20180711075736.jupakwgkxgjikcvr@esperanza>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180710183909.GF22105@chai>
References: <cover.1531065648.git.vdavydov.dev@gmail.com>
 <8ed8a5469d848dd627a3da1ac378cece942b27e5.1531065648.git.vdavydov.dev@gmail.com>
 <20180710121527.GB22105@chai>
 <20180710121942.d6lwkuoxsyhj65m5@esperanza>
 <20180710183909.GF22105@chai>
To: Konstantin Osipov <kostja@tarantool.org>
Cc: tarantool-patches@freelists.org
List-ID: <tarantool-patches.dev.tarantool.org>

On Tue, Jul 10, 2018 at 09:39:09PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [18/07/10 15:22]:
> > On Tue, Jul 10, 2018 at 03:15:27PM +0300, Konstantin Osipov wrote:
> > > * Vladimir Davydov <vdavydov.dev@gmail.com> [18/07/08 22:52]:
> > > > Since in presence of secondary indexes we read the primary index when
> > > > processing a REPLACE request anyway, we turn it into INSERT if no tuple
> > > > matching the new tuple is found so that INSERT+DELETE gets annihilated
> > > > on compaction.
> > > > 
> > > > However, in the scope of #2129 we are planning to optimize the read out
> > > > so that this transformation won't be possible anymore. So let's remove
> > > > it now.
> > > 
> > > Ugh. What if we deal with a space which has a unique secondary
> > > key, so optimization B is not applicable. You removed optimization
> > > A for all spaces. 
> > 
> > The optimization works even if secondary indexes are unique.
> 
> Only for deletes. But not for replace/upsert.

It works for REPLACE as well.

> 
> I thought you had the opinion that this optimization is
> controversial - so ideally it should be optional. What do you
> think now? Or you generally think that it's so controversial it's
> not worth it, and if we do, we should not make it optional?

I made it mandatory for the sake of testing. We might want to make it
optional one day - it isn't going to be a problem.