| From: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
|---|---|
| To: | John Mendenhall <john(at)surfutopia(dot)net> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: ported application having performance issues |
| Date: | 2005-07-01 08:57:02 |
| Message-ID: | Pine.LNX.4.44.0507011051320.4501-100000@zigo.dhs.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, 30 Jun 2005, John Mendenhall wrote:
> Our setting for effective_cache_size is 2048.
>
> random_page_cost = 4, effective_cache_size = 2048 time approximately 4500ms
> random_page_cost = 3, effective_cache_size = 2048 time approximately 1050ms
> random_page_cost = 3, effective_cache_size = 4096 time approximately 1025ms
>
> The decrease of random_page_cost to 3 caused the plan
> to work properly, using the lead_requests table as a
> join starting point and using the contacts index.
The effective_cache_size still looks small. As a rule of tumb you might
want effective_cache_size to be something like 1/2 or 2/3 of your total
memory. I don't know how much you had, but effective_cache_size = 4096 is
only 32M.
shared_buffers and effective_cache_size is normally the two most important
settings in my experience.
--
/Dennis Björklund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sam Mason | 2005-07-01 13:33:05 | planner picking more expensive plan |
| Previous Message | John Mendenhall | 2005-06-30 23:58:21 | Re: ported application having performance issues |