On 2021-May-27, Tom Lane wrote:
> 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.
Sorry, I'm unclear on exactly what are you proposing. Are you proposing
to rip out the fact that VACUUM FULL promises to recompress everything,
or are you proposing to rip out the whole attcompression feature?
Absolute -1 on the latter from me. Pluggable compression has taken
years to get to this point, it certainly won't do to give that up.
Now about the former. If we do think that recompressing causes an
unacceptable 10% slowdown for every single VACUUM FULLs, then yeah we
should discuss changing that behavior -- maybe remove promises of
recompression and wait for pg15 to add "VACUUM (RECOMPRESS)" or
similar.
If it's a 10% slowdown of the only best times (variability unspecified)
and only in corner cases (unlogged tables with no indexes that fit in
shared buffers), then I don't think we should bother.
--
Álvaro Herrera 39°49'30"S 73°17'W
"You're _really_ hosed if the person doing the hiring doesn't understand
relational systems: you end up with a whole raft of programmers, none of
whom has had a Date with the clue stick." (Andrew Sullivan)
