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
