| From: | Franco Bruno Borghesi <franco(at)akyasociados(dot)com(dot)ar> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Mapping a database completly into Memory |
| Date: | 2003-07-28 17:48:02 |
| Message-ID: | 1059414481.1957.1.camel@taz.oficina |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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 of our pages in
memory... I gues :)
On Mon, 2003-07-28 at 13:50, Josh Berkus wrote:
> 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 rely
> completely on the OS cache.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | scott.marlowe | 2003-07-28 17:58:11 | Re: Mapping Database completly into memory |
| Previous Message | Josh Berkus | 2003-07-28 17:10:02 | Re: Tuning PostgreSQL |