pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ashwin Agrawal <aagrawal@pivotal.io>
Cc: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Subject: Re: Zedstore - compressed in-core columnar storage
Date: Sun, 14 Apr 2019 18:39:47 +0200
Message-ID: <20190414163947.owdw4gyjui36rakf@development> (raw)
In-Reply-To: <d4bfe7b0-0836-06b1-6b03-f5874b5a2b00@iki.fi>
References: <CALfoeiuF-m5jg51mJUPm5GN8u396o5sA2AF5N97vTRAEDYac7w@mail.gmail.com>
	<fc2d4f99-1ca6-854f-7025-ec3db94f6e04@catalyst.net.nz>
	<f301066e-08e1-a4b6-e058-0c1f24a1cc92@catalyst.net.nz>
	<6A2B85A8-1ABD-4F85-981E-C94172D662FD@pivotal.io>
	<11257.1554994460@sss.pgh.pa.us>
	<d4bfe7b0-0836-06b1-6b03-f5874b5a2b00@iki.fi>

On Thu, Apr 11, 2019 at 06:20:47PM +0300, Heikki Linnakangas wrote:
>On 11/04/2019 17:54, Tom Lane wrote:
>>Ashwin Agrawal <aagrawal@pivotal.io> writes:
>>>Thank you for trying it out. Yes, noticed for certain patterns pg_lzcompress() actually requires much larger output buffers. Like for one 86 len source it required 2296 len output buffer. Current zedstore code doesn’t handle this case and errors out. LZ4 for same patterns works fine, would highly recommend using LZ4 only, as anyways speed is very fast as well with it.
>>
>>You realize of course that *every* compression method has some inputs that
>>it makes bigger.  If your code assumes that compression always produces a
>>smaller string, that's a bug in your code, not the compression algorithm.
>
>Of course. The code is not making that assumption, although clearly 
>there is a bug there somewhere because it throws that error. It's 
>early days..
>
>In practice it's easy to weasel out of that, by storing the data 
>uncompressed, if compression would make it longer. Then you need an 
>extra flag somewhere to indicate whether it's compressed or not. It 
>doesn't break the theoretical limit because the actual stored length 
>is then original length + 1 bit, but it's usually not hard to find a 
>place for one extra bit.
>

Don't we already have that flag, though? I see ZSCompressedBtreeItem has
t_flags, and there's ZSBT_COMPRESSED, but maybe it's more complicated.


-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 





view thread (123+ messages)  latest in thread

Message-ID: <20190414163947.owdw4gyjui36rakf@development>
Permalink:  ../20190414163947.owdw4gyjui36rakf@development/
Also on:    postgresql.org/message-id/20190414163947.owdw4gyjui36rakf@development

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@2ndquadrant.com, hlinnaka@iki.fi, tgl@sss.pgh.pa.us, aagrawal@pivotal.io, mark.kirkwood@catalyst.net.nz
  Subject: Re: Zedstore - compressed in-core columnar storage
  In-Reply-To: <20190414163947.owdw4gyjui36rakf@development>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox