X-Original-To: pgsql-hackers-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 2B0979FA68D for ; Tue, 25 Jul 2006 02:09:03 -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 04647-07 for ; Tue, 25 Jul 2006 02:08:59 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.envysolutions.com (mark.mielke.cc [206.248.142.186]) by postgresql.org (Postfix) with ESMTP id 202389FA4E0 for ; Tue, 25 Jul 2006 02:08:59 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.envysolutions.com (Postfix) with ESMTP id A5C037F2C6; Tue, 25 Jul 2006 01:08:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.envysolutions.com Received: from mail.envysolutions.com ([127.0.0.1]) by localhost (mark.mielke.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSYjM2j02ZIc; Tue, 25 Jul 2006 01:08:55 -0400 (EDT) Received: by mail.envysolutions.com (Postfix, from userid 500) id 6C1937F2C8; Tue, 25 Jul 2006 01:08:55 -0400 (EDT) Date: Tue, 25 Jul 2006 01:08:55 -0400 From: mark@mark.mielke.cc To: Tom Lane Cc: Bruce Momjian , Jie Zhang , Hannu Krosing , Gavin Sherry , pgsql-hackers@postgresql.org, Luke Lonergan Subject: Re: On-disk bitmap index patch Message-ID: <20060725050855.GA31414@mark.mielke.cc> References: <200607250104.k6P14St25388@momjian.us> <20060725015805.GA30087@mark.mielke.cc> <5085.1153802202@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5085.1153802202@sss.pgh.pa.us> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.145 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, NO_REAL_NAME, SPF_HELO_PASS, SPF_PASS X-Spam-Level: * X-Archive-Number: 200607/1123 X-Sequence-Number: 86978 On Tue, Jul 25, 2006 at 12:36:42AM -0400, Tom Lane wrote: > mark@mark.mielke.cc writes: > > Reading 1/4, for a larger table, has a good chance of being faster than > > reading 4/4 of the table. :-) > Really? > > If you have to hit one tuple out of four, it's pretty much guaranteed > that you will need to fetch every heap page. So using an index provides > zero I/O savings on the heap side, and any fetches needed to read the > index are pure cost. Now you have to demonstrate that the CPU costs > involved in processing the index are significantly cheaper than the cost > of just testing the WHERE qual at every heap tuple --- not a bet that's > likely to win at a one-in-four ratio. Haha. Of course - but that's assuming uniform spread of the values. Next I would try clustering the table on the bitmap index... :-) My databases aren't as large as many of yours. Most or all of them will fit in 1 Gbytes of RAM. The I/O cost isn't substantial for these, but the WHERE clause might be. But yeah - we don't know. Waste of code or performance boost. Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/