Re: 7.3.1 New install, large queries are slow - Mailing list pgsql-performance

From Curt Sampson
Subject Re: 7.3.1 New install, large queries are slow
Date
Msg-id Pine.NEB.4.51.0301271926400.393@angelic.cynic.net
Whole thread Raw
In response to Re: 7.3.1 New install, large queries are slow  (Sean Chittenden <sean@chittenden.org>)
Responses Re: 7.3.1 New install, large queries are slow  (Ron Johnson <ron.l.johnson@cox.net>)
List pgsql-performance
On Mon, 27 Jan 2003, Sean Chittenden wrote:

>     The FreeBSD VM caching system does prevent one process from exhausting
>     another process's cached data due to a sequential access, but the
>     FreeBSD VM cache does not try to outsmart sequential data accesses to
>     datasets which are larger then available cache space because it's an
>     insanely difficult (impossible) problem to solve properly without
>     foreknowledge of what data elements will be accessed when.

This is not impossible; Solaris does just this. I'm a little short of
time right now, but I can probably dig up the paper on google if nobody
else finds it.

Also, it is not hard to give the OS foreknowledge of your access
pattern, if you use mmap. Just call madvise and use the MADV_RANDOM,
MADV_SEQUENTIAL, MADV_WILLNEED and MADV_DONTNEED flags. (This is one
of the reasons I think we might see a performance improvement from
switching from regular I/O to mmap I/O.)

You can go back through the archives and see a much fuller discussion of
all of this.

cjs
--
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

pgsql-performance by date:

Previous
From: Curt Sampson
Date:
Subject: Re: LOCK TABLE & speeding up mass data loads
Next
From: Ron Johnson
Date:
Subject: Re: 7.3.1 New install, large queries are slow