Skip site navigation (1) Skip section navigation (2)

Re: 7.3.1 New install, large queries are slow

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
Cc: PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org>
Subject: Re: 7.3.1 New install, large queries are slow
Date: 2003-01-27 21:08:59
Message-ID: 200301272108.h0RL8xA05911@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
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."

---------------------------------------------------------------------------

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!!"                                          |
> +---------------------------------------------------------------+
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-performance by date

Next:From: Josh BerkusDate: 2003-01-27 21:12:09
Subject: Re: Indexing foreign keys
Previous:From: Matt MelloDate: 2003-01-27 20:56:38
Subject: Re: Indexing foreign keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group