Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id AC1321337B68 for ; Wed, 2 Feb 2011 15:31:53 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 71816-08 for ; Wed, 2 Feb 2011 19:31:46 +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 987CB1337999 for ; Wed, 2 Feb 2011 15:31:44 -0400 (AST) X-IronPort-AV: E=Sophos;i="4.60,415,1291611600"; d="scan'208";a="28360002" Received: from unknown (HELO lpo-mailbox-01.vmsinfo.com) ([216.169.137.251]) by lpo-relay-04.vmsinfo.com with ESMTP; 02 Feb 2011 14:31:44 -0500 Received: from [10.101.43.35] (unknown [216.169.135.235]) by lpo-mailbox-01.vmsinfo.com (Postfix) with ESMTP id 297007D00B for ; Wed, 2 Feb 2011 14:31:44 -0500 (EST) Message-ID: <4D49B11F.8090108@vmsinfo.com> Date: Wed, 02 Feb 2011 14:31:43 -0500 From: Mladen Gogala Organization: VMS User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "pgsql-performance@postgresql.org" Subject: [Fwd: Re: [HACKERS] Slow count(*) again...] Content-Type: text/plain; charset=utf-8; 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/38 X-Sequence-Number: 42176 I mistakenly replied to sender only. Jon Nelson wrote: > However, sometimes using an index results in a HORRIBLE HORRIBLE plan. > I recently encountered the issue myself, and plopping an ANALYZE > $tablename in there, since I was using a temporary table anyway, make > all the difference. The planner switched from an index-based query to > a sequential scan, and a sequential scan was (is) vastly more > efficient in this particular case. > That can be fixed by modifying the query. One can write the query in such a way that optimizer cannot use an index. > Personally, I'd get rid of autovacuum/autoanalyze support on temporary > tables (they typically have short lives and are often accessed > immediately after creation preventing the auto* stuff from being > useful anyway), *AND* every time I ask I'm always told "make sure > ANALYZE the table before you use it". > > I consider that requirement very bad. I hate it when I have to do things like this: try { $tmprows=array(); $db->StartTrans(); foreach ($result["matches"] as $doc => $docinfo) { $tmp=$result["matches"][$doc]["attrs"]["created"]; $tmprows[]=array(date($FMT,$tmp),$doc); } $db->Execute($TMPINS,$tmprows); $db->CommitTrans(); // Why the heck is this needed? $db->Execute("analyze tempids"); $tmprows=array(); if ($result["total_found"]>$result["total"]) { print "Total results:" . $result["total_found"] . "
"; print "Returned results:" . $result["total"] . "
"; } $result=array(); $rs = $db->Execute($IGEN, array($beg, $end)); show($fmt,$rs); } catch(Exception $e) { The "analyze tempids" line makes my code ugly and slows it down. -- 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 -- 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