| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | josh(at)agliodbs(dot)com |
| Cc: | Sean Chittenden <sean(at)chittenden(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Moving postgresql.conf tunables into 2003... |
| Date: | 2003-07-04 17:15:17 |
| Message-ID: | 27905.1057338917@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Tom Comments:
>> I was arguing awhile back for bumping the default shared_buffers up,
>> but the discussion trailed off with no real resolution.
> I think we ran up against the still far-too-low SHMMAX settings in most
> *nixes. We could raise this default once we can supply a script which will
> help the user bump up the OS's memory settings at, say, initDB time.
Actually, I think it would not be hard to get initdb to test whether
larger shared-memory settings would work. We could do something like
try -B of 64, 256, 512, 1024, and insert into postgresql.conf the
largest value that works. I would want it to top out at a few thousand
at most, because I don't think a default installation should try to
commandeer the whole machine, but if we could get the typical
installation to be running with even 1000 buffers rather than 64,
we'd be *way* better off. (See "Postgres vs MySQL" thread nearby.)
We could possibly also have initdb print some kind of message if it's
forced to use an unreasonably small value for shared_buffers, so that
people might have a clue that they need to do kernel reconfiguration.
Comments?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Sullivan | 2003-07-04 17:22:05 | Strange result: UNIX vs. TCP/IP sockets |
| Previous Message | Josh Berkus | 2003-07-04 17:12:36 | Re: PostgreSQL vs. MySQL |