> "BM" == Bruce Momjian <[EMAIL PROTECTED]> writes:
BM> I think it all depends on your working set. Having shared memory be
BM> smaller than you working set causes pages to have to be copied in from
BM> the kernel buffers (not a huge problem, but a small penalty), while
BM> having shared memo
You make an interesting distinction that read/write needs more shared
memory. I think this is because if you want to reused a read-only
shared buffer, you can just throw away the contents, while a dirty
buffer requires you to write it into the kernel before you can use it.
--
I think it all depends on your working set. Having shared memory be
smaller than you working set causes pages to have to be copied in from
the kernel buffers (not a huge problem, but a small penalty), while
having shared memory larger than the working set causes overhead of
searching through all
> "TL" == Tom Lane <[EMAIL PROTECTED]> writes:
TL> Franco Bruno Borghesi <[EMAIL PROTECTED]> writes:
>> wouldn't also increasing shared_buffers to 64 or 128 MB be a good
>> performance improvement? This way, pages belonging to heavily used
>> indexes would be already cached by the database its
Josh Berkus <[EMAIL PROTECTED]> writes:
>> If we had a portable way
>> of preventing the kernel from caching the same page, it would make more
>> sense to run with large shared_buffers.
> Really? I thought we wanted to move the other way ... that is, if we could
> get over the portability issues
But I think it's still a good option.
For example, in servers where there are other applications running (a web server, for example) that are constantly accesing the disk and replacing cached postgresql pages in the kernel, having shared buffers could reduce this efect and assure the precense
On Mon, Jul 28, 2003 at 12:25:57PM -0400, Tom Lane wrote:
> in the kernel's disk cache), thus wasting RAM. If we had a portable way
> of preventing the kernel from caching the same page, it would make more
> sense to run with large shared_buffers.
Plus, Postgres seems not to be very good at manag
Franco Bruno Borghesi <[EMAIL PROTECTED]> writes:
> wouldn't also increasing shared_buffers to 64 or 128 MB be a good
> performance improvement? This way, pages belonging to heavily used
> indexes would be already cached by the database itself.
Not necessarily. The trouble with large shared_buffe
Tom,
> If we had a portable way
> of preventing the kernel from caching the same page, it would make more
> sense to run with large shared_buffers.
Really? I thought we wanted to move the other way ... that is, if we could
get over the portability issues, eliminate shared_buffers entirely and r
wouldn't also increasing shared_buffers to 64 or 128 MB be a good performance improvement? This way, pages belonging to heavily used indexes would be already cached by the database itself.
Please, correct me if I'm wrong.
On Mon, 2003-07-28 at 01:14, Josh Berkus wrote:
Daniel,
> > I just wo
Daniel,
> > I just wondered if there is a possibility to map my database running
> > on a linux system completly into memory and to only use disk
> > accesses for writes.
>
> That happens for free, if you have enough RAM. The kernel will use
> spare RAM to hold copies of every disk block it's eve
Daniel Migowski <[EMAIL PROTECTED]> writes:
> I just wondered if there is a possibility to map my database running
> on a linux system completly into memory and to only use disk
> accesses for writes.
That happens for free, if you have enough RAM. The kernel will use
spare RAM to hold copies of e
12 matches
Mail list logo
