> something that just lets you get back to the old behavior. > Technically, the latter is good enough to avoid any claim that we've > regressed things:
yes, that is the intention with the GUC. I am worried about cases in which a user has no way to go back to the old behavior if the new prioritization strategy causes pain, for some reason. > But that only caters > to the scenario where the current behavior is good by accident > (because it can never be good for any other reason). Well, maybe it was never really good, but it was the only behavior, and the user tuned and tested their autovacuum settings with this behavior; whether they actually kew it's based on pg_class ordering or not ( I know users I worked with that do not realize this ). I think if we are to think how we can improve prioritization, the thing in mind is what can we do so users are no longer required to schedule manual vacuums for specific tables ( which is essentially how users are currently prioritizing tables ). If we go to rigid strategy that is being proposed now, will it reduce or eliminate the need for manually scheduling? I am not so sure. > Don't take this too literally, but just mooting ideas wildly, suppose > the scoring has a wraparound component, a bloat component, and a > reloption-driven component, and the former two have a weighting factor > that can be adjusted via GUCs. If you want to shut off the new > behavior, you can setting the weighting factors to 0. Something like this could. be better since it can both give control over prioritization and allows to revert to the current behavior. -- Sami Imseih Amazon Web Services (AWS)
