Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 175719FA3B0 for ; Sat, 23 Sep 2006 09:19:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 73828-01 for ; Sat, 23 Sep 2006 09:19:43 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.logix-tt.com (mail.logix-tt.com [212.211.145.186]) by postgresql.org (Postfix) with ESMTP id 733D49F9B01 for ; Sat, 23 Sep 2006 09:19:43 -0300 (ADT) Received: from kingfisher.intern.logix-tt.com (p549D38FA.dip0.t-ipconnect.de [84.157.56.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id 7109C65977 for ; Sat, 23 Sep 2006 14:22:02 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id 5B5C6181AC32F for ; Sat, 23 Sep 2006 14:19:43 +0200 (CEST) Message-ID: <4515265E.7080902@logix-tt.com> Date: Sat, 23 Sep 2006 14:19:42 +0200 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: "Pgsql-Performance ((E-mail))" Subject: Re: Confusion and Questions about blocks read References: <33c6269f0609220834x6c10db9xa40d6121825dfd14@mail.gmail.com> <780.1158942275@sss.pgh.pa.us> In-Reply-To: <780.1158942275@sss.pgh.pa.us> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.195 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200609/316 X-Sequence-Number: 21002 Hi, Tom, Tom Lane wrote: > "Alex Turner" writes: >> Home come the query statistics showed that 229066 blocks where read given >> that all the blocks in all the tables put together only total 122968? > > You forgot to count the indexes. Also, the use of indexscans in the > mergejoins probably causes multiple re-reads of some table blocks, > depending on just what the physical ordering of the rows is. As far as I understand, Index Bitmap Scans improve this behaviour, by ensuring that every table block is read only once. Btw, would it be feasible to enhance normal index scans by looking at all rows in the current table block whether they meet the query criteria, fetch them all, and blacklist the block for further revisiting during the same index scan? I think that, for non-sorted cases, this could improve index scans a little, but I don't know whether it's worth the effort, given that bitmap indidex scans exist. Thanks, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org