pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Andrey Borodin <amborodin86@gmail.com>
Cc: Ian Lawrence Barwick <barwick@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: pglz compression performance, take two
Date: Mon, 6 Feb 2023 02:51:27 +0100
Message-ID: <0f54129f-255d-2d8f-94a0-d18b6f388745@enterprisedb.com> (raw)
In-Reply-To: <CAAhFRxhCMG4b17SdheURdEF2AdByUXnrokqLV9Cas9qmKq7aJQ@mail.gmail.com>
References: <FEF3DC5E-4BC4-44E1-8DEB-DADC67046FE3@yandex-team.ru>
	<D75ABE30-2AAA-47DB-A89F-665E03BAAD2A@yandex-team.ru>
	<25991595-1848-4178-AA57-872B10309DA2@yandex-team.ru>
	<20201230043930.GG25152@telsasoft.com>
	<BF0A7E6D-AB21-47F8-A5FA-328CAA32DB12@yandex-team.ru>
	<20210122024811.GE27167@telsasoft.com>
	<EB24F56E-901B-46D6-BFFC-71D51603ABDE@enterprisedb.com>
	<88C049C6-1B86-4EF7-940D-585B07FEB81B@yandex-team.ru>
	<90649B7F-EF71-40F7-93D0-1029AD0D90F3@enterprisedb.com>
	<B1D3105C-D68B-445F-B3DF-E3F41FE79C46@enterprisedb.com>
	<84aa2da0-004d-c8f8-48c8-aa2861d1ff73@enterprisedb.com>
	<120DD821-48F4-446C-865A-093E560A2143@yandex-team.ru>
	<CAB8KJ=h5q3Cn8YPezQCQHGCgA5r=XOEfeZb_tW+8YY1JQfK1xQ@mail.gmail.com>
	<bcf3e6ee-44a1-5615-bb3d-0eb9531b6e8c@enterprisedb.com>
	<CAAhFRxhFvuO-yUu8VuT3k6jKeJUjzA0ff3rJS6qtPLHdq3Epzg@mail.gmail.com>
	<CAAhFRxg4cinQ=Wy9QCaFuojFM9qPpWpwvUSdqkPcsDcwqAiMog@mail.gmail.com>
	<CAAhFRxhCMG4b17SdheURdEF2AdByUXnrokqLV9Cas9qmKq7aJQ@mail.gmail.com>

On 2/5/23 19:36, Andrey Borodin wrote:
> On Fri, Jan 6, 2023 at 10:02 PM Andrey Borodin <amborodin86@gmail.com> wrote:
>>
>> Hello! Please find attached v8.
> 
> I got some interesting feedback from some patch users.
> There was an oversight that frequently yielded results that are 1,2 or
> 3 bytes longer than expected.
> Looking closer I found that the correctness of the last 3-byte tail is
> checked in two places. PFA fix for this. Previously compressed data
> was correct, however in some cases few bytes longer than the result of
> current pglz implementation.
> 

Thanks. What were the consequences of the issue? Lower compression
ratio, or did we then fail to decompress the data (or would current pglz
implementation fail to decompress it)?


regards

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





view thread (32+ messages)  latest in thread

Message-ID: <0f54129f-255d-2d8f-94a0-d18b6f388745@enterprisedb.com>
Permalink:  ../0f54129f-255d-2d8f-94a0-d18b6f388745@enterprisedb.com/
Also on:    postgresql.org/message-id/0f54129f-255d-2d8f-94a0-d18b6f388745@enterprisedb.com

 · 

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@enterprisedb.com, amborodin86@gmail.com, barwick@gmail.com, x4mmm@yandex-team.ru, mark.dilger@enterprisedb.com, pryzby@telsasoft.com
  Subject: Re: pglz compression performance, take two
  In-Reply-To: <0f54129f-255d-2d8f-94a0-d18b6f388745@enterprisedb.com>

* 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