From: Tom Lane <tgl@sss.pgh.pa.us>
To: 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 10:39:51 -0400
Message-ID: <1719337.1622126391@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+TgmoaOnOem=5dacsWqhWHoRO9tvnOuAnseWnR3_mYG-8J5Dg@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>
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, May 27, 2021 at 10:18 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>>> [ shrug... ] I think the history of the SET STORAGE option teaches us
>>> that there is no such requirement, and you're inventing a scenario that
>>> doesn't exist in the real world.
>> But can we compare SET STORAGE with SET compression? I mean storage
>> just controls how the data are stored internally and there is no
>> external dependency. But if we see the compression it will have a
>> dependency on the external library. So if the user wants to get rid
>> of the dependency on the external library then IMHO, there should be
>> some way to do it by recompressing all the data.
> TBH, I'm more concerned about the other direction. Surely someone who
> upgrades from an existing release to v14 and sets their compression
> method to lz4 is going to want a way of actually converting their data
> to using lz4. 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.
What I'm hearing is a whole lot of hypothesizing and zero evidence of
actual field requirements. On the other side of the coin, we've already
wasted significant person-hours on fixing this feature's memory leakage,
and now people are proposing to expend more effort on solving^Wpapering
over its performance issues by adding yet more user-visible complication.
It's already adding too much user-visible complication IMO --- I know
because I was just copy-editing the documentation about that yesterday.
I say it's time to stop the bleeding and rip it out. When and if
there are actual field requests to have a way to do this, we can
discuss what's the best way to respond to those requests. Hacking
VACUUM probably isn't the best answer, anyway. But right now,
we are past feature freeze, and I think we ought to jettison this
one rather than quickly kluge something.
regards, tom lane
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, 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: <1719337.1622126391@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