From: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
---|---|
To: | PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: 7.3.1 New install, large queries are slow |
Date: | 2003-01-28 01:42:41 |
Message-ID: | 1043718161.9896.120.camel@haggis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "Fear the Penguin!!" |
+---------------------------------------------------------------+
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Mello | 2003-01-28 05:46:46 | Re: Indexing foreign keys |
Previous Message | Ron St.Pierre | 2003-01-28 00:06:51 | Re: Indexing foreign keys |