[RFC PATCH 01/23] vinyl: do not turn REPLACE into INSERT when processing DML request

Konstantin Osipov kostja at tarantool.org
Tue Jul 10 21:39:09 MSK 2018


* Vladimir Davydov <vdavydov.dev at gmail.com> [18/07/10 15:22]:
> On Tue, Jul 10, 2018 at 03:15:27PM +0300, Konstantin Osipov wrote:
> > * Vladimir Davydov <vdavydov.dev at 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.

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



More information about the Tarantool-patches mailing list