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

  • From: Vladimir Davydov <vdavydov.dev@xxxxxxxxx>
  • To: Konstantin Osipov <kostja@xxxxxxxxxxxxx>
  • Date: Wed, 11 Jul 2018 10:57:36 +0300

On Tue, Jul 10, 2018 at 09:39:09PM +0300, Konstantin Osipov wrote:

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

Other related posts: