Skip site navigation (1) Skip section navigation (2)

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 (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Mon, 2004-07-26 at 08:20, Gaetano Mendola wrote:
> Hervé Piedvache wrote:


> > 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

pgsql-performance by date

Next:From: Harmon S. NineDate: 2004-07-26 18:37:48
Subject: Re: Timestamp-based indexing
Previous:From: Stephan SzaboDate: 2004-07-26 16:02:03
Subject: Re: Timestamp-based indexing

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group