Re: Potential autovacuum optimization: new tables - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: Potential autovacuum optimization: new tables
Date
Msg-id CAFNqd5W3AxTcmZY+qjA-pgTbGfaK0LZtaCpwK+t0fr5RDuxyWg@mail.gmail.com
Whole thread Raw
In response to Re: Potential autovacuum optimization: new tables  (Joshua Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Sat, Oct 13, 2012 at 3:49 PM, Joshua Berkus <josh@agliodbs.com> wrote:
> So, problem #1 is coming up with a mathematical formula.  My initial target values are in terms of # of rows in the
tablevs. # of writes before analyze is triggered:
 
>
> 1 : 3
> 10 : 5
> 100 : 10
> 1000 : 100
> 100000 : 2000
> 1000000 : 5000
> 10000000 : 25000
> 100000000 : 100000

Do we necessarily care about smoothness?

If we don't at all, then this would be fine:

func powerlaw (tuples int) int {if tuples < 10 {    return 3}if tuples < 100 {    return 5}if tuples < 1000 {    return
10}iftuples < 100000 {    return 100}if tuples < 1000000 {    return 2000}if tuples < 10000000 {    return 5000}if
tuples< 100000000 {    return 25000}return 100000
 
}

If we want smoothness within the ranges, this is a piecewise linear
representation of your table:

func powerlaw2 (tuples int) int {if tuples < 10 {    return 3}if tuples < 100 {    return 5 + 5 * (tuples - 90)/90}if
tuples< 1000 {    return 10 + 90 * (tuples - 900)/900}if tuples < 100000 {    return 100 + 1900 * (tuples -
99000)/99000}iftuples < 1000000 {    return 2000 + 3000 * (tuples - 900000)/900000}if tuples < 10000000 {    return
5000+ 22000 * (tuples - 9000000)/9000000}if tuples < 100000000 {    return 25000 + 75000 * (tuples -
90000000)/90000000}return100000    
 
}

That's in Go, but there shouldn't be anything too unfamiliar looking
about it :-).

It would be nice to have a simpler functional representation, but the
above is by no means heinous, and it's not verbose beyond reason.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: smgrsettransient mechanism is full of bugs
Next
From: Andrew Dunstan
Date:
Subject: Re: Deprecating RULES