Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 9945E1337B6C for ; Wed, 27 Oct 2010 19:36:43 -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 57898-08 for ; Wed, 27 Oct 2010 22:36:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 5A3331337B5C for ; Wed, 27 Oct 2010 19:36:36 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o9RMaZZr029672; Wed, 27 Oct 2010 18:36:35 -0400 (EDT) To: Jon Nelson cc: pgsql-performance@postgresql.org Subject: Re: temporary tables, indexes, and query plans In-reply-to: References: <4CC864F8.3060801@vmsinfo.com> <7C0800F63CCF4149AC0FC5EE2A041226D52361@sr002-2k3exc.ateb.com> <26190.1288208593@sss.pgh.pa.us> <29004.1288215953@sss.pgh.pa.us> Comments: In-reply-to Jon Nelson message dated "Wed, 27 Oct 2010 17:02:43 -0500" Date: Wed, 27 Oct 2010 18:36:35 -0400 Message-ID: <29671.1288218995@sss.pgh.pa.us> From: Tom Lane 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/519 X-Sequence-Number: 40937 Jon Nelson writes: > I'd like to zoom out a little bit and, instead of focusing on the > specifics, ask more general questions: > - does the table being temporary effect anything? Another lister > emailed me and wondered if ANALYZE on a temporary table might behave > differently. Well, the autovacuum daemon can't do anything with temp tables, so you're reliant on doing a manual ANALYZE if you want the planner to have stats. Otherwise it should be the same. > - is there some way for me to determine /why/ the planner chooses a > sequential scan over other options? It thinks it's faster, or there is some reason why it *can't* use the index, like a datatype mismatch. You could tell which by trying "set enable_seqscan = off" to see if that will make it change to another plan; if so, the estimated costs of that plan versus the original seqscan would be valuable information. > - in the general case, are indexes totally ready to use after creation > or is an analyze step necessary? They are unless you said CREATE INDEX CONCURRENTLY, which doesn't seem like it's relevant here; but since you keep on not showing us your code, who knows? > - do hint bits come into play here at all? No. regards, tom lane