From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: Robert Haas <robertmhaas@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>,
        Michael Paquier <michael@paquier.xyz>,
        Andres Freund <andres@anarazel.de>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced
 size?
In-reply-to: 
 <CAH2-WznwfNu77VTJK5-6gNAD2EWiX6YK1Hcamfz4OrHg0hKkGw@mail.gmail.com>
References: <YKtpZI4PBpVG3ryH@paquier.xyz>
 <CAFiTN-vpHrCzdeyKxpoPViyJCZZx-h8KghQJFyxZd7+Dys6Cow@mail.gmail.com>
 <YKyPM6UC+tBHEuxo@paquier.xyz>
 <20210527003144.xxqppojoiwurc2iz@alap3.anarazel.de>
 <1677691.1622075746@sss.pgh.pa.us>
 <20210527015415.ctuj4yrwnjip5kve@alap3.anarazel.de>
 <20210527021402.b5n2sqw66y2fd6fl@alap3.anarazel.de>
 <1683251.1622083422@sss.pgh.pa.us>
 <20210527032105.xistjgattubmjymm@alap3.anarazel.de>
 <1685584.1622086493@sss.pgh.pa.us> <YK8aVuS0+8JOe8IM@paquier.xyz>
 <1687119.1622088698@sss.pgh.pa.us>
 <CA+TgmoZ1jiHNcpjjUkxAhjxWFo83oMHjpeaCvyAh0K6bPbvzFg@mail.gmail.com>
 <1709324.1622122448@sss.pgh.pa.us>
 <CAFiTN-ss6qKRU4XR6u41F_hOxYQK7Xz4Qk8yP7nNq7W5gEGnQg@mail.gmail.com>
 <CA+TgmoaOnOem=5dacsWqhWHoRO9tvnOuAnseWnR3_mYG-8J5Dg@mail.gmail.com>
 <CAH2-WznwfNu77VTJK5-6gNAD2EWiX6YK1Hcamfz4OrHg0hKkGw@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Thu, 27 May 2021 12:57:38 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1886209.1622147384.1@sss.pgh.pa.us>
Date: Thu, 27 May 2021 16:29:44 -0400
Message-ID: <1886210.1622147384@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1886210.1622147384%40sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> On Thu, May 27, 2021 at 7:25 AM Robert Haas <robertmhaas@gmail.com> wrote:
>> To say that nobody cares about that is to deem the
>> feature useless. Maybe that's what Tom thinks, but it's not what I
>> think.

> I don't think that follows at all.

Yeah.  My belief here is that users might bother to change
default_toast_compression, or that we might do it for them in a few
years, but the gains from doing so are going to be only incremental.
That being the case, most DBAs will be content to allow the older
compression method to age out of their databases through routine row
updates.  The idea that somebody is going to be excited enough about
this to run a downtime-inducing VACUUM FULL doesn't really pass the
smell test.

That doesn't make LZ4 compression useless, by any means, but it does
suggest that we shouldn't be adding overhead to VACUUM FULL for the
purpose of easing instantaneous switchovers.

I'll refrain from re-telling old war stories about JPEG/GIF/PNG, but
I do have real-world experience with compression algorithm changes.
IME you need an integer-multiples type of improvement to get peoples'
attention, and LZ4 isn't going to offer that, except maybe in
cherry-picked examples.

			regards, tom lane