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

From Ron Johnson
Subject Re: 7.3.1 New install, large queries are slow
Date
Msg-id 1043718161.9896.120.camel@haggis
Whole thread Raw
In response to Re: 7.3.1 New install, large queries are slow  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-performance
On Mon, 2003-01-27 at 15:08, Bruce Momjian wrote:
> Detecting sequential scan and increasing read-ahead is a standard OS
> capability, and most/all do that already.  Solaris has code to detect
> when a sequential scan is wiping the cache and adjusting the buffer
> frees, called "free-behind."

Ah, didn't know that.

> ---------------------------------------------------------------------------
>
> Ron Johnson wrote:
> > On Mon, 2003-01-27 at 04:34, Curt Sampson wrote:
> > > 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
> >
> > Quite.  One way to do it is:
> > - the OS notices that process X has been sequentially reading thru
> >   file Y for, say, 3 seconds.
> > - the OS knows that X is currently at the mid-point of file Y
> > - OS says, "Hey, I think I'll be a bit more agressive about, when I
> >   have a bit of time, trying to read Y faster than X is requesting
> >   it
> >
> > It wouldn't work well, though, in a client-server DB like Postgres,
> > which, in a busy multi-user system, is constantly hitting different
> > parts of different files.
> >
> > The algorithm, though, is used in the RDBMS Rdb.  It uses the algorithm
> > above, substituting "process X" for "client X", and passes the agressive
> > reads of Y on to the OS.  It's a big win when processing a complete
> > table, like during a CREATE INDEX, or  "SELECT foo, COUNT(*)" where
> > there's no index on foo.

--
+---------------------------------------------------------------+
| Ron Johnson, Jr.        mailto:ron.l.johnson@cox.net          |
| Jefferson, LA  USA      http://members.cox.net/ron.l.johnson  |
|                                                               |
| "Fear the Penguin!!"                                          |
+---------------------------------------------------------------+


pgsql-performance by date:

Previous
From: "Ron St.Pierre"
Date:
Subject: Re: Indexing foreign keys
Next
From: Matt Mello
Date:
Subject: Re: Indexing foreign keys