From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 97A0346970E for ; Fri, 24 Jan 2020 14:21:41 +0300 (MSK) Received: by mail-lf1-f66.google.com with SMTP id m30so867820lfp.8 for ; Fri, 24 Jan 2020 03:21:41 -0800 (PST) Date: Fri, 24 Jan 2020 14:21:34 +0300 From: Konstantin Osipov Message-ID: <20200124112134.GA8586@atlas> References: <60fbcb8d59f04632ca31976bdf537afffe8e8e5f.1578951026.git.i.kosarev@tarantool.org> <37bd8a76-11b5-e560-8bf8-acaa2539eaaf@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37bd8a76-11b5-e560-8bf8-acaa2539eaaf@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH v2 2/2] memtx: increase the memory quota if needed to truncate or delete List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org * Vladislav Shpilevoy [20/01/15 00:03]: > Thanks for the patch! > > JFI, I am still against this patch. It adds huge and > unnecessary complexity to the code, which we will need > to support forever. It is just not worth the pros the > patch gives. I don't get why insertion of truncation tuple can not use the same reserved memory segments which are used for RTREE recovery. We can just one +1 blog to the reserved list to accommodate for truncate. -- Konstantin Osipov, Moscow, Russia