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