Re: Potential autovacuum optimization: new tables

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Potential autovacuum optimization: new tables
Date: 2012-10-13 02:03:18
Message-ID: 28432.1350093798@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> I remember having got voted down on the percentage approach back when
>> we first put AV into core, but I remain convinced that decision was a
>> bad one.

> Yeah, I was one of the ones voting against you. The reason not to have
> percentage-only is for small tables. Imagine that you have a table with
> 18 rows, and analyze_threshold is 0 and analyze_scale_factor is 0.1.

[ 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.

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?

> Can anyone think of a new heuristic which doesn't involve adding 2-6 new
> GUCS knobs?

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2012-10-13 02:11:59 Re: Potential autovacuum optimization: new tables
Previous Message Josh Berkus 2012-10-13 01:49:48 Re: Potential autovacuum optimization: new tables