Re: Insert are going slower ...

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

In response to

Browse pgsql-performance by date

  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