On Wed, Jul 11, 2018 at 10:57:36AM +0300, Vladimir Davydov wrote:
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.
