From: | "Scott Marlowe" <smarlowe(at)qwest(dot)net> |
---|---|
To: | "Gaetano Mendola" <mendola(at)bigfoot(dot)com> |
Cc: | " Hervé Piedvache" <footcow(at)noos(dot)fr>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Insert are going slower ... |
Date: | 2004-07-26 16:25:38 |
Message-ID: | 1090859137.22512.12.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, 2004-07-26 at 08:20, Gaetano Mendola wrote:
> Hervé Piedvache wrote:
SNIP
> > sort_mem = 512000
>
> This is too much, you are instructing Postgres to use 512MB
> for each backend ( some time each backend can use this quantity
> more then one )
agreed. If any one process needs this much sort mem, you can set it in
that sessions with set sort_mem anyway, so to let every sort consume up
to 512 meg is asking for trouble.
> > effective_cache_size = 5000000
>
> 5GB for 8 GB system is too much
No, it's not. Assuming that postgresql with all it's shared buffers is
using <2 gig, it's quite likely that the kernel is caching at least 5
gigs of disk data. Effective cache size doesn't set any cache size, it
tells the planner about how much the kernel is caching.
> > random_page_cost = 3
>
> on your HW you can decrease it to 2
> and also decrease the other cpu costs
On fast machines it often winds up needing to be set somewhere around
1.2 to 2.0
From | Date | Subject | |
---|---|---|---|
Next Message | Harmon S. Nine | 2004-07-26 18:37:48 | Re: Timestamp-based indexing |
Previous Message | Stephan Szabo | 2004-07-26 16:02:03 | Re: Timestamp-based indexing |