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

  • From: Konstantin Osipov <kostja@xxxxxxxxxxxxx>
  • To: Vladimir Davydov <vdavydov.dev@xxxxxxxxx>
  • Date: Tue, 10 Jul 2018 21:39:09 +0300

* 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.

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

Other related posts:

  1. Home
  2. tarantool-patches
  3. Archive
  4. 07-2018