Re: 7.3.1 New install, large queries are slow
От | Ron Johnson |
---|---|
Тема | Re: 7.3.1 New install, large queries are slow |
Дата | |
Msg-id | 1043718161.9896.120.camel@haggis обсуждение исходный текст |
Ответ на | Re: 7.3.1 New install, large queries are slow (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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 по дате отправления: