From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vdavydov.dev@gmail.com>
Date: Wed, 6 Feb 2019 19:48:32 +0300
From: Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [tarantool-patches] Re: [PATCH 3/9] vinyl: use uncompressed run
 size for range split/coalesce/compaction
Message-ID: <20190206164832.7kkqiv36ffvuc4ut@esperanza>
References: <cover.1548017258.git.vdavydov.dev@gmail.com>
 <fff9b3eddaeeb73ae19c2ff277b1ec49052bc030.1548017258.git.vdavydov.dev@gmail.com>
 <20190205164355.GB6811@chai>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190205164355.GB6811@chai>
To: Konstantin Osipov <kostja@tarantool.org>
Cc: tarantool-patches@freelists.org
List-ID: <tarantool-patches.dev.tarantool.org>

On Tue, Feb 05, 2019 at 07:43:55PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [19/01/21 06:58]:
> > Historically, when considering splitting or coalescing a range or
> > updating compaction priority, we use sizes of compressed runs (see
> > bytes_compressed). This makes the algorithms dependent on whether
> > compression is used or not and how effective it is, which is weird,
> > because compression is a way of storing data on disk - it shouldn't
> > affect the way data is partitioned. E.g. if we turned off compression
> > at the first LSM tree level, which would make sense, because it's
> > relatively small, we would affect the compaction algorithm because
> > of this.
> > 
> 
> OK to push.

Pushed to 2.1 and 1.10.