Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id CDAA0B5DBD5
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed,  8 Jun 2011 14:04:01 -0300 (ADT)
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 23821-04
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed,  8 Jun 2011 17:03:50 +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 46C3EB5D94C
	for <pgsql-performance@postgresql.org>;
	Wed,  8 Jun 2011 14:03:50 -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 p58H3nGR014545;
	Wed, 8 Jun 2011 13:03:49 -0400 (EDT)
To: Tony Capobianco <tcapobianco@prospectiv.com>
cc: Stephen Frost <sfrost@snowman.net>, pgsql-performance@postgresql.org
Subject: Re: Oracle v. Postgres 9.0 query performance 
In-reply-to: <1307550486.1990.29.camel@tony1.localdomain> 
References: <1307545892.1990.23.camel@tony1.localdomain>
	<10260.1307547185@sss.pgh.pa.us>
	<1307547634.1990.26.camel@tony1.localdomain>
	<20110608155159.GA18128@tamriel.snowman.net>
	<1307550486.1990.29.camel@tony1.localdomain>
Comments: In-reply-to Tony Capobianco <tcapobianco@prospectiv.com>
	message dated "Wed, 08 Jun 2011 12:28:06 -0400"
Date: Wed, 08 Jun 2011 13:03:49 -0400
Message-ID: <14544.1307552629@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
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: 201106/78
X-Sequence-Number: 44011

Tony Capobianco <tcapobianco@prospectiv.com> writes:
> Well, this ran much better.  However, I'm not sure if it's because of
> set enable_nestloop = 0, or because I'm executing the query twice in a
> row, where previous results may be cached.  I will try this setting in
> my code for when this process runs later today and see what the result
> is.

If the performance differential holds up, you should look at adjusting
your cost parameters so that the planner isn't so wrong about which one
is faster.  Hacking enable_nestloop is a band-aid, not something you
want to use in production.

Looking at the values you gave earlier, I wonder whether the
effective_cache_size setting isn't unreasonably high.  That's reducing
the estimated cost of accessing the large table via indexscans, and
I'm thinking it reduced it too much.

			regards, tom lane