Re: 7.3.1 New install, large queries are slow

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: 7.3.1 New install, large queries are slow
Дата
Msg-id 200301272108.h0RL8xA05911@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: 7.3.1 New install, large queries are slow  (Ron Johnson <ron.l.johnson@cox.net>)
Ответы Re: 7.3.1 New install, large queries are slow
Список 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.l.johnson@cox.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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

В списке pgsql-performance по дате отправления:

Предыдущее
От: Matt Mello
Дата:
Сообщение: Re: Indexing foreign keys
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Indexing foreign keys