| From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
|---|---|
| To: | Chris Mckenzie <Chris(dot)McKenzie(at)entrust(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 22:54:38 |
| Message-ID: | 20060502225438.GL97354@pervasive.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, May 02, 2006 at 05:47:15PM -0400, Chris Mckenzie wrote:
> 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.
It's there in head...
decibel(at)phonebook(dot)1[17:52]~/pgsql/HEAD/src:4%grep -ri vacuum_cost_delay *|wc -l
8
> 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.
Huh? pg_statio shouldn't present a large penalty AFAIK...
--
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 | Ian Burrell | 2006-05-02 22:55:57 | Nested loop join and date range query |
| Previous Message | Jan de Visser | 2006-05-02 22:49:48 | Re: Performance Issues on Opteron Dual Core |