Subject: Re: Zedstore - compressed in-core columnar storage
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Soumyadeep Chakraborty <soumyadeep2007@gmail.com>,
 Alexandra Wang <lewang@pivotal.io>, Taylor Vesely <tvesely@pivotal.io>,
 Ashutosh Sharma <ashu.coek88@gmail.com>, Heikki Linnakangas
 <hlinnaka@iki.fi>, Ashwin Agrawal <aagrawal@pivotal.io>,
 DEV_OPS <devops@ww-it.cn>,
 PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
References: <bf4b8f5f-90c9-025d-013c-87cf998204ad@postgrespro.ru>
 <ed9dfcfb-871f-f6e6-6463-4ab47b4cb273@iki.fi>
 <CAE9k0PmpREo_xtQb_CqTFCKetmHv1LfMHWKpHgOA7geabLCnzQ@mail.gmail.com>
 <CAE9k0P=eQy6Cd7ptQ39CiEgL1E4E7Ur5VbHhtpTfJPW-G5pPMA@mail.gmail.com>
 <CACiyaSoMg684uPYGG4YsmgNpEmiMgoEuMm342_Xe8-5q9ma5yg@mail.gmail.com>
 <CAE9k0P=E_8pTPOQLcv5kRXTKSLU0Q_YjBq8eWB0yWvwS_yNqEw@mail.gmail.com>
 <CAE9k0PnTx=T6dHxwLRV5unn1Hxk_e-T9Mh36GAyUjgMnBY0itQ@mail.gmail.com>
 <3554cb64-3c77-ae98-491e-91f3221e37c1@iki.fi>
 <CAE9k0PmgJm9HfXAo0yEf2+3igcxpwxHTg+GKmtKEC6oaR1kVrA@mail.gmail.com>
 <CAFaX_4LbenqERsEMbxfTYXzpmvysL_p=o2G-tgDZs_=6eiryCw@mail.gmail.com>
 <CAFaX_4JSDxyiPavZ-2bdjTjY18Szm74fHMKntPGHQuSBuhuteg@mail.gmail.com>
 <CACiyaSqAOXngeu+yx1WgVfeLxGzMdTiyGamh2VG1iQgROOt_Dw@mail.gmail.com>
 <CAE-ML+-HwY4X4uTzBesLhOotHF7rUvP2Ur-rvEpqz2PUgK4K3g@mail.gmail.com>
 <9e1077bc-c5c1-425b-07ad-424d3522363f@enterprisedb.com>
 <CAHyXU0xa3=xtEN8M_UKfWVPCry-tXBPBbJurMKKGGV9z7J=gQw@mail.gmail.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
Message-ID: <f090d405-c5ac-835e-fdb3-0c8d9c850012@enterprisedb.com>
Date: Mon, 16 Nov 2020 17:07:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: 
 <CAHyXU0xa3=xtEN8M_UKfWVPCry-tXBPBbJurMKKGGV9z7J=gQw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 11/16/20 1:59 PM, Merlin Moncure wrote:
> On Thu, Nov 12, 2020 at 4:40 PM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
>>            master    zedstore/pglz    zedstore/lz4
>>   -------------------------------------------------
>>    copy      1855            68092            2131
>>    dump       751              905             811
>>
>> And the size of the lineitem table (as shown by \d+) is:
>>
>>   master: 64GB
>>   zedstore/pglz: 51GB
>>   zedstore/lz4: 20GB
>>
>> It's mostly expected lz4 beats pglz in performance and compression
>> ratio, but this seems a bit too extreme I guess. Per past benchmarks
>> (e.g. [1] and [2]) the difference in compression/decompression time
>> should be maybe 1-2x or something like that, not 35x like here.
> 
> I can't speak to the ratio, but in basic backup/restore scenarios pglz
> is absolutely killing me; Performance is just awful; we are cpubound
> in backups throughout the department.  Installations defaulting to
> plgz will make this feature show very poorly.
> 

Maybe. I'm not disputing that pglz is considerably slower than lz4, but
judging by previous benchmarks I'd expect the compression to be slower
maybe by a factor of ~2x. So the 30x difference is suspicious. Similarly
for the compression ratio - lz4 is great, but it seems strange it's 1/2
the size of pglz. Which is why I'm speculating that something else is
going on.

As for the "plgz will make this feature show very poorly" I think that
depends. I think we may end up with pglz doing pretty well (compared to
heap), but lz4 will probably outperform that. OTOH for various use cases
it may be more efficient to use something else with worse compression
ratio, but allowing execution on compressed data, etc.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company