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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2003-01-27 21:12:09 Re: Indexing foreign keys
Previous Message Matt Mello 2003-01-27 20:56:38 Re: Indexing foreign keys