X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id BB60011F605C for ; Fri, 21 Apr 2006 01:31:51 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.274 X-Spam-Level: X-Spam-Status: No, score=0.274 required=5 tests=[AWL=0.274] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id KR09v-6IZXOw for ; Fri, 21 Apr 2006 01:31:48 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id B2BBF11F6C52 for ; Fri, 21 Apr 2006 01:31:48 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id E88D956431; Thu, 20 Apr 2006 23:31:47 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Thu, 20 Apr 2006 23:31:47 -0500 Date: Thu, 20 Apr 2006 23:31:47 -0500 From: "Jim C. Nasby" To: Wu Fengguang , pgsql-performance@postgresql.org Subject: Re: Introducing a new linux readahead framework Message-ID: <20060421043147.GV49405@pervasive.com> References: <20060421013826.GA5217@mail.ustc.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060421013826.GA5217@mail.ustc.edu.cn> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060421:wfg@mail.ustc.edu.cn::dhdGYnup1eZC4beE:00000000000000000 0000000000000000000000001xhN X-Hashcash: 1:20:060421:pgsql-performance@postgresql.org::s8mdlecibDykISyn:00000 0000000000000000000000002fWB X-Archive-Number: 200604/489 X-Sequence-Number: 18573 On Fri, Apr 21, 2006 at 09:38:26AM +0800, Wu Fengguang wrote: > Greetings, > > I'd like to introduce a new readahead framework for the linux kernel: > http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/1021.html > > HOW IT WORKS > > In adaptive readahead, the context based method may be of particular > interest to postgresql users. It works by peeking into the file cache > and check if there are any history pages present or accessed. In this > way it can detect almost all forms of sequential / semi-sequential read > patterns, e.g. > - parallel / interleaved sequential scans on one file > - sequential reads across file open/close > - mixed sequential / random accesses > - sparse / skimming sequential read > > It also have methods to detect some less common cases: > - reading backward > - seeking all over reading N pages Are there any ways to inform the kernel that you either are or aren't doing a sequential read? It seems that in some cases it would be better to bypass a bunch of tricky logic trying to determine that it's doing a sequential read. A sequential scan in PostgreSQL would be such a case. The opposite example would be an index scan of a highly uncorrelated index, which would produce mostly random reads from the table. In that case, reading ahead probably makes very little sense, though your logic might have a better idea of the access pattern than PostgreSQL does. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461