Re: DB cache size strategies

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: NTPT <ntpt(at)centrum(dot)cz>
Cc: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: DB cache size strategies
Date: 2004-02-11 15:38:56
Message-ID: Pine.LNX.4.33.0402110836190.32376-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 11 Feb 2004, NTPT wrote:

> Take 1900 ms.. In this case i try to increase effective_cache_size step
> by step 64,128,256,512,1024 but increase effective_cache_size up from
> 512 have no dramatic impact on performance.

Note that effective_cache_size ONLY affects the query plan chosen. It has
no effect on the actual size of the kernel or postgresql caches. It is
just a hint to the planner about how large the kernel cache is.

> I test shared_buffer settings, between 2*max_connection ie 128*2 to
> 1024 but have no dramatic impact on performance, but in my tests no
> focus on this

If the data you're tossing around is ~1 Megabyte, then having more than 1
megabyte in shared buffers won't help. Basically, if shared buffers is
smaller than the data you're throwing about, then increasing it tends to
help, if it's larger than the amount of data being pulled / joined / etc..
then it doesn't help to make it larger.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Iker Arizmendi 2004-02-11 15:45:55 Function parameters of rowtype
Previous Message Jean-Michel POURE 2004-02-11 14:41:41 Re: Converting timestamps and IP addresses