From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 10 Jul 2018 21:39:09 +0300 From: Konstantin Osipov Subject: Re: [RFC PATCH 01/23] vinyl: do not turn REPLACE into INSERT when processing DML request Message-ID: <20180710183909.GF22105@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180710121942.d6lwkuoxsyhj65m5@esperanza> References: <8ed8a5469d848dd627a3da1ac378cece942b27e5.1531065648.git.vdavydov.dev@gmail.com> <20180710121527.GB22105@chai> <20180710121942.d6lwkuoxsyhj65m5@esperanza> To: Vladimir Davydov Cc: tarantool-patches@freelists.org List-ID: * Vladimir Davydov [18/07/10 15:22]: > On Tue, Jul 10, 2018 at 03:15:27PM +0300, Konstantin Osipov wrote: > > * Vladimir Davydov [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. 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? -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov