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

[Vladimir Davydov <vdavydov.dev@gmail.com>]

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.