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)
