Re: 7.3.1 New install, large queries are slow
| От | Andrew Sullivan |
|---|---|
| Тема | Re: 7.3.1 New install, large queries are slow |
| Дата | |
| Msg-id | 20030118112426.A23790@mail.libertyrms.com обсуждение |
| Ответ на | Re: 7.3.1 New install, large queries are slow (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-performance |
On Fri, Jan 17, 2003 at 11:49:31PM -0500, Tom Lane wrote:
> Jeff <threshar@torgo.978.org> writes:
> > Informix, oracle, etc all do raw device access bypassing the kernels
> > buffering, etc. So they need heaping gobules of memory to do the same
> > thing the kernel does..
>
> D'oh, I believe Jeff's put his finger on it. You need lotsa RAM if you
> are trying to bypass the OS. But Postgres would like to work with the
> OS, not bypass it.
One of the interesting things I have been playing with on Solaris
recently is the various no-buffer settings you can give to the kernel
for filesystems. The idea is that you don't have the kernel do the
buffering, and you set your database's shared memory setting
_reeeeal_ high.
As nearly as I can tell, there is again no benefit with PostgreSQL.
I'd also be amazed if this approach is a win for other systems. But
a lot of DBAs seem to believe that they know better than their
computers which tables are "really" accessed frequently. I think
they must be smarter than I am: I'd rather trust a system that was
designed to track these things and change the tuning on the fly,
myself.
(To be fair, there are some cases where you have an
infrequently-accessed table which nevertheless is required to be fast
for some reason or other, so you might want to force it to stay in
memory.)
A
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
В списке pgsql-performance по дате отправления: