From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 1 Aug 2018 19:03:49 +0300 From: Vladimir Davydov Subject: Re: [PATCH 25/25] vinyl: eliminate disk read on REPLACE/DELETE Message-ID: <20180801160348.nelovcmzvike5mkx@esperanza> References: <20180731205552.GR15235@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180731205552.GR15235@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Tue, Jul 31, 2018 at 11:55:52PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [18/07/27 16:55]: > > When executing a REPLACE or DELETE request for a vinyl space, we need to > > delete the old tuple from secondary indexes if any, e.g. if there's a > > space with the primary index over field 1 and a secondary index over > > field 2 and there's REPLACE{1, 10} in the space, then REPLACE{1, 20} has > > to generate DELETE{10, 1} in order to overwrite REPLACE{10, 1} before > > inserting REPLACE{20, 1} into the secondary index. Currently, we > > generate DELETEs for secondary indexes immediately on request execution, > > which makes REPLACE/DELETE operations disk-bound in case the space has > > secondary indexes, because in order to delete the old tuple we have to > > look it up in the primary index first. > > Please salvage Vlad's test coverage. There's nothing to salvage. Vlad's tests check that 1. REPLACE/DELETE don't do lookups in the primary index. 2. SELECT from a secondary index skips stale tuples. 3. Stale tuples are not stored in the tuple cache. 4. Tuples that were overwritten in a transaction write set are not committed. 5. Purging stale tuples on compaction. 6. Generation of "deleruns". The tests added by this patch cover all those cases except 6, which is irrelevant, and even more: recovery, purging stale tuples on commit, out of memory handling while generating deferred DELETEs on compaction.