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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2006-09-25 17:37:06 | Re: serial column |
Previous Message | Bob Pawley | 2006-09-25 15:59:51 | Re: serial column |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2006-09-25 17:53:00 | Re: Release Notes: Major Changes in 8.2 |
Previous Message | Stefan Kaltenbrunner | 2006-09-25 16:51:08 | Re: -HEAD planner issue wrt hash_joins on dbt3 ? |