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

In response to

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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 ?