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

Re: Increase default effective_cache_size?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Russ Brown <pickscrape(at)gmail(dot)com>
Subject: Re: Increase default effective_cache_size?
Date: 2006-09-25 17:07:17
Message-ID: 11617.1159204037@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Initdb does not currently make any attempt to discover the extent of 
> physical or virtual memory, it simply tries to start postgres with 
> certain shared_buffer settings, starting at 4000, and going down until 
> we get a success.

> max_fsm_pages is now fixed proportionally with shared_buffers, and I 
> guess we could do something similar with effective_cache_size, but since 
> IIRC this doesn't involve shared memory I'm inclined to agree with Tom 
> that it should just be fixed at some substantially higher level.

Right, the default shared_buffers doesn't have much of anything to do
with actual RAM size.  If the user has altered it, then it might (or
might not) ... but that doesn't help us for setting a default
effective_cache_size.

Barring objections, I'll change it to Josh Drake's suggestion of ~ 128Mb
(versus current 8Mb).

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Andrew SullivanDate: 2006-09-25 17:53:00
Subject: Re: Release Notes: Major Changes in 8.2
Previous:From: Stefan KaltenbrunnerDate: 2006-09-25 16:51:08
Subject: Re: -HEAD planner issue wrt hash_joins on dbt3 ?

pgsql-general by date

Next:From: Jeff DavisDate: 2006-09-25 17:37:06
Subject: Re: serial column
Previous:From: Bob PawleyDate: 2006-09-25 15:59:51
Subject: Re: serial column

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