Re: 8.0.0beta3 vacuum analyze

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: 8.0.0beta3 vacuum analyze
Date: 2004-10-18 12:49:42
Message-ID: m3mzykdwd5.fsf@knuth.knuth.cbbrowne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

In the last exciting episode, pgsql(at)bluepolka(dot)net ("Ed L.") wrote:
> I *think* I'm seeing "vacuum analyze" queries launched automatically on an
> 8.0.0beta3 (unless I have a rogue autovac running that I haven't spotted).
> Is this something new in 8.0 and to be expected?
>
> My settings:
>
> #vacuum_cost_delay = 0 # 0-1000 milliseconds
> #vacuum_cost_page_hit = 1 # 0-10000 credits
> #vacuum_cost_page_miss = 10 # 0-10000 credits
> #vacuum_cost_page_dirty = 20 # 0-10000 credits
> #vacuum_cost_limit = 200 # 0-10000 credits

None of this would cause vacuums to be initiated.

The above configuration settings allow making vacuums "relatively
lazy;" instead of them running full-bore, and killing cache/chewing
I/O, they can do a few blocks worth of work, and then sleep a bit.

They are all commented out, so they won't have _any_ effect.

Note that this "lazier vacuuming" can be run alongside ARC to get some
synergistic benefit:

- ARC prevents vacuums from trashing the shared memory cache;

- "lazy vacuum" / "vacuum delay" prevents vacuums from taking over
all I/O
--
let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/
Fatal Error: Found [MS-Windows] System -> Repartitioning Disk for
Linux...
-- <cbbrowne(at)hex(dot)net> Christopher Browne

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruno Wolff III 2004-10-18 14:19:39 Re: Avoiding sequential scans with OR join condition
Previous Message nd02tsk 2004-10-18 12:20:06 How to time several queries?