Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 8C56C9F9ECD for ; Wed, 11 Oct 2006 17:28:19 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 64990-08 for ; Wed, 11 Oct 2006 20:28:03 +0000 (UTC) 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 001D19F9F80 for ; Wed, 11 Oct 2006 17:28:02 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 7424F56435; Wed, 11 Oct 2006 15:28:01 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 11 Oct 2006 15:27:58 -0500 Date: Wed, 11 Oct 2006 15:27:58 -0500 From: "Jim C. Nasby" To: Bucky Jordan Cc: Tom Lane , Brian Herlihy , Postgresql Performance Subject: Collect stats during seqscan (was: Simple join optimized badly?) Message-ID: <20061011202758.GQ13487@nasby.net> References: <15661.1160534309@sss.pgh.pa.us> <78ED28FACE63744386D68D8A9D1CF5D4209C7A@MAIL.corp.lumeta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78ED28FACE63744386D68D8A9D1CF5D4209C7A@MAIL.corp.lumeta.com> 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:061011:bjordan@lumeta.com::wuqR4lAezyvXWkNe:0000000000000000000 0000000000000000000000000CQ+ X-Hashcash: 1:20:061011:tgl@sss.pgh.pa.us::l6IRqz5DbUrIskt7:00000000000000000000 0000000000000000000000005mLP X-Hashcash: 1:20:061011:btherl@yahoo.com.au::hECjrS8oPuHVoZRs:000000000000000000 00000000000000000000000099as X-Hashcash: 1:20:061011:pgsql-performance@postgresql.org::iCkn23iIcTgJ/3IH:00000 000000000000000000000000GBlH X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200610/226 X-Sequence-Number: 21355 On Wed, Oct 11, 2006 at 10:27:26AM -0400, Bucky Jordan wrote: > Also, I'm guessing this has already come up at some point, but what > about allowing PG to do some stat collection during queries? If you're > touching a lot of data (such as an import process) wouldn't it be more > efficient (and perhaps more accurate) to collect stats then, rather than > having to re-scan? It would be nice to be able to turn this on/off on a > per query basis, seeing as it could have pretty negative impacts on OLTP > performance... I suspect that could be highly useful in data warehouse environments where you're more likely to have to sequential scan a table. It would be interesting to have it so that a sequential scan that will run to completion also collects stats along the way. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)