Re: Postgres 7.4 and vacuum_cost_delay.

From: Chris Mckenzie <Chris(dot)McKenzie(at)entrust(dot)com>
To: 'Andrew Sullivan' <ajs(at)crankycanuck(dot)ca>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres 7.4 and vacuum_cost_delay.
Date: 2006-05-04 14:49:06
Message-ID: DE02FD24E5A7504FA1D53631DA8CEA9BF8B641@sottmxs10.entrust.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hey, thanks for the advice.

Sticking with 7.4 isn't my call. There's a lot wrapped up in common usage of
Postgres 7.4 and I could never rally everyone into moving forward. (at least
not this year)

I've yet to prove (due to my current lack of statistical evidence) that our
usage of 7.4 results in frequent vacuums impacting access. (it get more
difficult to speculate when considering a large slony cluster) I'm hoping to
gather some times and numbers on an internal dogfood of our product shortly.

Any advice on tracking vacuum performance and impact? I was thinking of just
system timing the vacuumdb calls and turning on verbose for per-table/index
stats. Do you think that's enough info?

Once I vacuum I won't be able to re-test any fragmentation that the vacuum
cleaned up, so its all or nothing for this test.

Thanks again.

- Chris

-----Original Message-----
From: pgsql-performance-owner(at)postgresql(dot)org
[mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Andrew Sullivan
Sent: Thursday, May 04, 2006 8:28 AM
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Postgres 7.4 and vacuum_cost_delay.

On Tue, May 02, 2006 at 05:47:15PM -0400, Chris Mckenzie wrote:
> I've come to the conclusion I need to simply start tracking all
> transactions and determining a cost/performance for the larger and
> frequently updated tables without the benefit and penalty of
> pg_statio.

I'll bet it won't help you. If you can't get off 7.4 on a busy machine,
you're going to get hosed by I/O sometimes no matter what.
My suggestion is to write a bunch of rule-of-thumb rules for your cron jobs,
and start planning your upgrade.

Jan back-patched the vacuum stuff to 7.4 for us (Afilias), and we tried
playing with it; but it didn't really make the difference we'd hoped.

The reason for this is that 7.4 also doesn't have the bg_writer. So you're
still faced with I/O storms, no matter what you do. If I were in your
shoes, I wouldn't waste a lot of time on trying to emulate the new features
in 7.4.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
In the future this spectacle of the middle classes shocking the avant- garde
will probably become the textbook definition of Postmodernism.
--Brad Holland

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Browse pgsql-performance by date

  From Date Subject
Next Message Jim C. Nasby 2006-05-04 17:47:21 Re: Performance Issues on Opteron Dual Core
Previous Message Mario Splivalo 2006-05-04 14:45:57 Re: Lot'sa joins - performance tip-up, please?