> [ shrug... ] You're attacking a straw man, or more precisely putting > words into my mouth about what the percentage-based thresholds might be. > Notice the examples I gave involved update percentages quite far north > of 100%. It's possible and maybe likely that we need a sliding scale.
Yes, or a logarithmic one. > Also, I don't necessarily accept the conclusion you seem to be drawing, > that it's okay to have complete turnover of a small table and not redo > its stats. I'm not drawing that conclusion. I'm explaining the logic of autovacuum_analyze_threshold. That logic actually works pretty well for tables between 200 rows and 200,000 rows. It's outside of those boundaries where it starts to break down. > The increased number of knobs may be a problem, but I don't think we can > avoid having more. Your own complaint is that the current design is too > simplistic. Replacing it with a different but equally simplistic design > probably won't help much. Well, we could do something which involves no GUCS at all, which would be my favorite approach. For example, Frost and I were discussing this on IRC. Imagine if autovac threshold were set according to a simple log function, resulting in very small tables getting analyzed after 100% changes, and very large tables getting analyzed after 0.1% changes, and everyone else between? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
