From: | Bill Moran <wmoran(at)collaborativefusion(dot)com> |
---|---|
To: | "Campbell, Lance" <lance(at)uiuc(dot)edu> |
Cc: | "Richard Huxton" <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Recommended Initial Settings |
Date: | 2007-02-23 18:11:37 |
Message-ID: | 20070223131137.06824192.wmoran@collaborativefusion.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
In response to "Campbell, Lance" <lance(at)uiuc(dot)edu>:
> Richard,
> Thanks for your reply.
>
> You said:
> "Your operating-system should be doing the caching for you."
>
> My understanding is that as long as Linux has memory available it will
> cache files. Then from your comment I get the impression that since
> Linux would be caching the data files for the postgres database it would
> be redundant to have a large shared_buffers. Did I understand you
> correctly?
Keep in mind that keeping the data in the kernel's buffer requires
Postgres to make a syscall to read a file, which the kernel then realizes
is cached in memory. The kernel then has to make that data available
to the Postgres (userland) process.
If the data is in Postgres' buffers, Postgres can fetch it directly, thus
avoiding the overhead of the syscalls and the kernel activity. You still
have to make sysvshm calls, though.
So, it depends on which is able to manage the memory better. Is the
kernel so much more efficient that it makes up for the overhead of the
syscalls? My understanding is that in recent versions of Postgres,
this is not the case, and large shared_buffers improve performance.
I've yet to do any in-depth testing on this, though.
--
Bill Moran
Collaborative Fusion Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2007-02-23 18:14:29 | long checkpoint_timeout |
Previous Message | msmbarabino@virgilio.it | 2007-02-23 17:55:20 | Re: Very slow bytea data extraction |