Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 351D31337B90 for ; Wed, 2 Feb 2011 14:11:42 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 72925-02 for ; Wed, 2 Feb 2011 18:11:35 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from lpo-relay-04.vmsinfo.com (lpo-relay-04.vmsinfo.com [216.169.137.115]) by mail.postgresql.org (Postfix) with ESMTP id D756A1337B6E for ; Wed, 2 Feb 2011 14:11:34 -0400 (AST) X-IronPort-AV: E=Sophos;i="4.60,415,1291611600"; d="scan'208";a="28357932" Received: from unknown (HELO lpo-mailbox-02.vmsinfo.com) ([216.169.137.251]) by lpo-relay-04.vmsinfo.com with ESMTP; 02 Feb 2011 13:11:34 -0500 Received: from [10.101.43.35] (lpo-autonomy-p03.vmsinfo.com [216.169.135.234]) by lpo-mailbox-02.vmsinfo.com (Postfix) with ESMTP id ED36E56272; Wed, 2 Feb 2011 13:11:33 -0500 (EST) Message-ID: <4D499E55.4020107@vmsinfo.com> Date: Wed, 02 Feb 2011 13:11:33 -0500 From: Mladen Gogala Organization: VMS User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Robert Haas CC: Andrew Dunstan , Bruce Momjian , Tom Lane , "david@lang.hm" , Craig Ringer , Vitalii Tymchyshyn , "pgsql-performance@postgresql.org" Subject: Re: [HACKERS] Slow count(*) again... References: <201102012247.p11Ml6u02682@momjian.us> <4D48914B.4050403@dunslane.net> <4D489AD1.1010105@vmsinfo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/28 X-Sequence-Number: 42166 Robert Haas wrote: > On Tue, Feb 1, 2011 > It would be pretty hard to make autoanalyze work on such tables > without removing some of the performance benefits of having such > tables in the first place - namely, the local buffer manager. But you > could ANALYZE them by hand. > > Not necessarily autoanalyze, some default rules for the situations when stats is not there should be put in place, like the following: 1) If there is a usable index on the temp table - use it. 2) It there isn't a usable index on the temp table and there is a join, make the temp table the first table in the nested loop join. People are complaining about the optimizer not using the indexes all over the place, there should be a way to make the optimizer explicitly prefer the indexes, like was the case with Oracle's venerable RBO (rules based optimizer). RBO didn't use statistics, it had a rank of access method and used the access method with the highest rank of all available access methods. In practice, it translated into: if an index exists - use it. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions