From: | Chris Mckenzie <Chris(dot)McKenzie(at)entrust(dot)com> |
---|---|
To: | "'Jim C(dot) Nasby'" <jnasby(at)pervasive(dot)com> |
Cc: | "'pgsql-performance(at)postgresql(dot)org'" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Postgres 7.4 and vacuum_cost_delay. |
Date: | 2006-05-02 21:47:15 |
Message-ID: | DE02FD24E5A7504FA1D53631DA8CEA9BF8B62E@sottmxs10.entrust.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Thanks.
My first check was of course a grep/search of the postgres.conf, next it was
a complete source grep for vacuum_cost_delay.
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.
- Chris
-----Original Message-----
From: Jim C. Nasby [mailto:jnasby(at)pervasive(dot)com]
Sent: Tuesday, May 02, 2006 5:39 PM
To: Chris Mckenzie
Cc: 'pgsql-performance(at)postgresql(dot)org'
Subject: Re: [PERFORM] Postgres 7.4 and vacuum_cost_delay.
show all and grep are your friend. From my laptop with 8.1:
decibel(at)phonebook(dot)1[16:36]~:4%psql -tc 'show all' | grep
vacuum_cost_delay|tr -s ' ' autovacuum_vacuum_cost_delay | -1 | Vacuum cost
delay in milliseconds, for autovacuum. vacuum_cost_delay | 0 | Vacuum cost
delay in milliseconds. decibel(at)phonebook(dot)1[16:37]~:5%
I don't have a 7.4 copy around, but you can just check it yourself.
On Mon, May 01, 2006 at 02:40:41PM -0400, Chris Mckenzie wrote:
> Hi everyone.
>
> I've got a quick and stupid question: Does Postgres 7.4 (7.x) support
> vacuum_cost_delay?
>
> For all my googles and documentation reading I've determined it's not
> supported, only because I can't find a 7.x doc or forum post claiming
> otherwise.
>
> Upgrading to 8.x is out of the question, but I still need to employ
> something to auto-vacuum a large and active database (possibly more
> than once a day) in a manner that wouldn't affect load at the wrong
> time.
>
> If I could combine pg_autovacuum with vacuum_cost_delay I could
> potentially have a solution. (barring some performance testing)
>
> The only problem with pg_autovacuum is the need for pg_statio, which
> itself will reduce performance at all times.
>
> Any suggestions?
>
> Thanks!
>
> - Chris
>
>
>
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-05-02 21:53:30 | Re: Slow restoration question |
Previous Message | Jim C. Nasby | 2006-05-02 21:46:37 | Re: postgresql transaction id monitoring with nagios |