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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Date: Thu, 27 May 2021 16:29:44 -0400
Message-ID: <1886210.1622147384@sss.pgh.pa.us> (raw)
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>

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





view thread (73+ messages)  latest in thread

Message-ID: <1886210.1622147384@sss.pgh.pa.us>
Permalink:  ../1886210.1622147384@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/1886210.1622147384@sss.pgh.pa.us

 · 

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: tgl@sss.pgh.pa.us, pg@bowt.ie, robertmhaas@gmail.com, dilipbalaut@gmail.com, michael@paquier.xyz, andres@anarazel.de
  Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
  In-Reply-To: <1886210.1622147384@sss.pgh.pa.us>

* 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