X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx2.hub.org [200.46.204.254]) by postgresql.org (Postfix) with ESMTP id A9E0911F8D3C for ; Thu, 20 Apr 2006 13:27:39 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from postgresql.org ([200.46.204.71]) by localhost (mx2.hub.org [200.46.204.254]) (amavisd-new, port 10024) with ESMTP id 50yPnF-qIS9w for ; Thu, 20 Apr 2006 13:27:35 -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 9C56B11F8D39 for ; Thu, 20 Apr 2006 13:27:34 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 708A656423; Thu, 20 Apr 2006 11:27:33 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Thu, 20 Apr 2006 11:27:32 -0500 Date: Thu, 20 Apr 2006 11:27:32 -0500 From: "Jim C. Nasby" To: Tom Lane Cc: Mark Kirkwood , Markus Schaber , pgsql-performance@postgresql.org Subject: Re: merge>hash>loop Message-ID: <20060420162732.GX49405@pervasive.com> References: <1145029009.3422.31.camel@spectre.intellivid.com> <10000.1145031205@sss.pgh.pa.us> <1145033149.3422.41.camel@spectre.intellivid.com> <11035.1145033929@sss.pgh.pa.us> <4444C4CF.2000106@logix-tt.com> <20060418215238.GK49405@pervasive.com> <19388.1145398946@sss.pgh.pa.us> <20060418231552.GN49405@pervasive.com> <4445C0EC.2060407@paradise.net.nz> <22250.1145424328@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22250.1145424328@sss.pgh.pa.us> 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:060420:tgl@sss.pgh.pa.us::SJGoPJ6sKgO6tDNb:00000000000000000000 0000000000000000000000000rHI X-Hashcash: 1:20:060420:markir@paradise.net.nz::NmwQ3L4yVpZVjFMX:000000000000000 00000000000000000000000006dy X-Hashcash: 1:20:060420:schabi@logix-tt.com::dJS7wqgizaYEbrW1:000000000000000000 0000000000000000000000000Jaw X-Hashcash: 1:20:060420:pgsql-performance@postgresql.org::yX22HI0Rqo55/RHa:00000 0000000000000000000000004Zt1 X-Archive-Number: 200604/460 X-Sequence-Number: 18544 On Wed, Apr 19, 2006 at 01:25:28AM -0400, Tom Lane wrote: > Mark Kirkwood writes: > > Jim C. Nasby wrote: > >> Good point. :/ I'm guessing there's no easy way to see how many blocks > >> for a given relation are in shared memory, either... > > > contrib/pg_buffercache will tell you this - > > I think the key word in Jim's comment was "easy", ie, cheap. Grovelling > through many thousands of buffers to count the matches to a given > relation doesn't sound appetizing, especially not if it gets done over > again several times during each query-planning cycle. Trying to keep > centralized counts somewhere would be even worse (because of locking/ > contention issues). Very true. OTOH, it might not be unreasonable to periodically slog through the buffers and store that information, perhaps once a minute, or every X number of transactions. I think a bigger issue is that we currently have no way to really measure the effictiveness of the planner. Without that it's impossible to come up with any real data on whether cost formula A is better or worse than cost formula B. The only means I can think of for doing this would be to measure estimated cost vs actual cost, but with the overhead of EXPLAIN ANALYZE and other variables that might not prove terribly practical. Maybe someone else has some ideas... -- 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