Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 7915A133740B for ; Thu, 3 Feb 2011 15:24:52 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 56115-01-4 for ; Thu, 3 Feb 2011 19:24:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from cooker.cnx.rice.edu (cooker.cnx.rice.edu [168.7.5.70]) by mail.postgresql.org (Postfix) with ESMTP id BA3DD1337BCD for ; Thu, 3 Feb 2011 15:24:43 -0400 (AST) Received: from reedstrm by cooker.cnx.rice.edu with local (Exim 4.69) (envelope-from ) id 1Pl4nK-0007ko-GV for pgsql-performance@postgresql.org; Thu, 03 Feb 2011 13:24:42 -0600 Date: Thu, 3 Feb 2011 13:24:42 -0600 From: "Ross J. Reedstrom" To: pgsql-performance@postgresql.org Subject: Re: [HACKERS] Slow count(*) again... Message-ID: <20110203192442.GF31926@rice.edu> References: <4D489AD1.1010105@vmsinfo.com> <4D499E55.4020107@vmsinfo.com> <4D49A6B9.4060608@2ndquadrant.com> <4D49C482.4010707@vmsinfo.com> <4D49F0BA.9000901@2ndquadrant.com> <4D4A16BF.1020304@vmsinfo.com> <4D4A4844.3020409@2ndquadrant.com> <4D4AD9F6.6040903@vmsinfo.com> <87d3n92etk.fsf@cbbrowne.afilias-int.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d3n92etk.fsf@cbbrowne.afilias-int.info> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201102/103 X-Sequence-Number: 42241 On Thu, Feb 03, 2011 at 12:44:23PM -0500, Chris Browne wrote: > mladen.gogala@vmsinfo.com (Mladen Gogala) writes: > > Hints are not even that complicated to program. The SQL parser should > > compile the list of hints into a table and optimizer should check > > whether any of the applicable access methods exist in the table. If it > > does - use it. If not, ignore it. This looks to me like a > > philosophical issue, not a programming issue. > > It's worth looking back to what has already been elaborated on in the > ToDo. > > http://wiki.postgresql.org/wiki/Todo > ----------------------------------- > Optimizer hints (not wanted) > > Optimizer hints are used to work around problems in the optimizer and > introduce upgrade and maintenance issues. We would rather have the > problems reported and fixed. We have discussed a more sophisticated > system of per-class cost adjustment instead, but a specification remains > to be developed. And as to the 'wait around for a new version to fix that': there are constantly excellent examples of exactly this happening, all the time with PostgreSQL - most recent example I've seen - http://archives.postgresql.org/pgsql-performance/2011-01/msg00337.php The wait often isn't long, at all. Ross -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Systems Engineer & Admin, Research Scientist phone: 713-348-6166 Connexions http://cnx.org fax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE