Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 4E3131337B5C for ; Wed, 27 Oct 2010 14:44:33 -0300 (ADT) 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 20775-02 for ; Wed, 27 Oct 2010 17:44:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from lpo-relay-05.vmsinfo.com (lpo-relay-05.vmsinfo.com [216.169.137.116]) by mail.postgresql.org (Postfix) with ESMTP id 05DC6133798F for ; Wed, 27 Oct 2010 14:44:25 -0300 (ADT) X-IronPort-AV: E=Sophos;i="4.58,247,1286164800"; d="scan'208";a="29649766" Received: from unknown (HELO lpo-mailbox-02.vmsinfo.com) ([216.169.137.252]) by lpo-relay-05.vmsinfo.com with ESMTP; 27 Oct 2010 13:44:24 -0400 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 63DF356258 for ; Wed, 27 Oct 2010 13:44:24 -0400 (EDT) Message-ID: <4CC864F8.3060801@vmsinfo.com> Date: Wed, 27 Oct 2010 13:44:24 -0400 From: Mladen Gogala User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: temporary tables, indexes, and query plans References: In-Reply-To: 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: 201010/482 X-Sequence-Number: 40900 On 10/27/2010 1:29 PM, Jon Nelson wrote: > I have an app which imports a lot of data into a temporary table, does > a number of updates, creates some indexes, and then does a bunch more > updates and deletes, and then eventually inserts some of the columns > from the transformed table into a permanent table. > > Things were not progressing in a performant manner - specifically, > after creating an index on a column (INTEGER) that is unique, I > expected statements like this to use an index scan: > > update foo set colA = 'some value' where indexed_colB = 'some other value' > > but according to the auto_explain module (yay!) the query plan > (always) results in a sequential scan, despite only 1 row getting the > update. > > In summary, the order goes like this: > > BEGIN; > CREATE TEMPORARY TABLE foo ...; > copy into foo .... > UPDATE foo .... -- 4 or 5 times, updating perhaps 1/3 of the table all told > CREATE INDEX ... -- twice - one index each for two columns > ANALYZE foo; -- didn't seem to help > UPDATE foo SET ... WHERE indexed_column_B = 'some value'; -- seq scan? > Out of 10 million rows only one is updated! > ... > > What might be going on here? > How big is your default statistics target? The default is rather small, it doesn't produce very good or usable histograms. -- 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