From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Potential autovacuum optimization: new tables |
Date: | 2012-10-13 02:13:39 |
Message-ID: | 20121013021339.GE29165@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> [ 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.
I was just discussing such a sliding scale approach w/ Josh on IRC, my
thinking was that we could use a logarithmic approach based on table
size.
> 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. If you don't like the current behavior when there's no
> stats, why would you like the behavior when there are some stats but
> they no longer have the remotest relationship to reality?
Josh's concern is about autovacuum causing lots of stats churn, which is
understandable, we don't want it constantly rescanning a table, but
perhaps we could use some kind of threshold for preventing autovac from
rescanning a table it just scanned? Note that I did *not* say 'GUC',
but I don't know what the 'right' answer is for how frequently is
good-but-not-too-frequent. I'd also like to try and avoid adding GUCs.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | David Johnston | 2012-10-13 02:50:33 | Re: Potential autovacuum optimization: new tables |
Previous Message | Josh Berkus | 2012-10-13 02:11:59 | Re: Potential autovacuum optimization: new tables |