X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 299249DCAB2 for ; Tue, 29 Nov 2005 01:08:27 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 09198-03 for ; Tue, 29 Nov 2005 01:08:25 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 220019DCA9F for ; Tue, 29 Nov 2005 01:08:23 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id AFDF131F4D; Tue, 29 Nov 2005 06:08:19 +0100 (MET) From: "Qingqing Zhou" X-Newsgroups: pgsql.hackers Subject: Re: ice-broker scan thread Date: Tue, 29 Nov 2005 00:09:11 -0500 Organization: Hub.Org Networking Services Lines: 31 Message-ID: References: <438BD013.1000804@boreham.org> X-Complaints-To: usenet@news.hub.org X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 To: pgsql-hackers@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.049 required=5 tests=[AWL=0.049] X-Spam-Score: 0.049 X-Spam-Level: X-Archive-Number: 200511/1462 X-Sequence-Number: 76744 "David Boreham" wrote > > BTW, I heard a long time ago that NTFS has quite fancy read-ahead, where > it attempts to detect the application's access pattern including if it is > reading sequentially and even if there is a 'stride' to the accesses when > they're not contiguous. I would imagine that other filesystems attempt > similar tricks. So one might expect a simple linear prefectch > to not help much in the presence of such a filesystem. > So we need more tests. I understand how smart current file systems are, and seems that depends on the interval that you send next file block read request (decided by cpu_cost parameter in my program). I imagine on a multi-way machine with strong IO device, the ice-breaker could do much better ... > Were you worried about the icebreaker thread getting too far ahead of the > scan ? If it did it might page out the data you're about to read, I think. > Of course this could be fixed by having the read ahead thread perodically > check the current location being read by the query thread and pausing if > it's got too far ahead. > Right. Regards, Qingqing