DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=xOCDZ8JfQ67wdUdwehO6veS4JUYoudNcrlxspoUxeVehTpf5UCYcW4UKFpHMKKvr0/
	Nov/oajmsJF6JYJJTTImo66jxdBaVeNyEV0EFZTaEm2ZvWbAgRkW9UnwBXiyDtnGxftB
	Gc17wN1Vl+eYyVWh4FGeH3IqazrLcXCN9X/Mk=
MIME-Version: 1.0
In-Reply-To: <1ca6422a7addad0207f758f54300dd0b.squirrel@semichrome.net>
References: <1ca6422a7addad0207f758f54300dd0b.squirrel@semichrome.net>
Date: Tue, 10 Mar 2009 17:19:53 -0600
Message-ID: <dcc563d10903101619j4c668570m1e3fdc9a539f7acd@mail.gmail.com>
Subject: Re: Query performance over a large proportion of data
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Steve McLellan <smclellan@mintel.com>
Cc: pgsql-performance@postgresql.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 10, 2009 at 3:12 PM, Steve McLellan <smclellan@mintel.com> wrot=
e:
>
> =A0Nested Loop =A0(cost=3D466.34..192962.24 rows=3D15329 width=3D12) (act=
ual
> time=3D13653.238..31332.113 rows=3D131466 loops=3D1)


Both your query plans end with this nested loop join which is taking
up about half your time in your query.  Notice the estimation of the
result set is off by a factor of about 10  here, which means a nested
loop might be not so good a choice for this.  Try increasing default
stats target and re-analyzing to see if that helps.  1000 is the max
you can give that a shot right off to see if it helps.  If it does,
drop it until the numbers start to go off again and stop.

For a quicker test, you can set enable_nestloop =3D off in the psql
command line and then run the query by hand and see if that helps.