To: Samuel Gendler <sgendler@ideasculptor.com>
cc: pgsql-performance@postgresql.org
Subject: Re: yet another q 
In-reply-to: <AANLkTimvgOTbFgaWc8z0irHr+LrObDbbvxR49xSCeNfd@mail.gmail.com> 
References: <AANLkTimvgOTbFgaWc8z0irHr+LrObDbbvxR49xSCeNfd@mail.gmail.com>
Comments: In-reply-to Samuel Gendler <sgendler@ideasculptor.com>
	message dated "Wed, 18 Aug 2010 23:14:10 -0700"
Date: Thu, 19 Aug 2010 12:28:23 -0400
Message-ID: <7713.1282235303@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Samuel Gendler <sgendler@ideasculptor.com> writes:
> fast plan: http://explain.depesz.com/s/iZ
> slow plan: http://explain.depesz.com/s/Dv2

Your problem here is that it's switching from hash aggregation to
sort-and-group-aggregate once it decides that the number of aggregate
groups won't fit in work_mem anymore.  While you could brute-force
that by raising work_mem, it'd be a lot better if you could get the
estimated number of groups more in line with the actual.  Notice the
very large discrepancy between the estimated and actual numbers of
rows out of the aggregation steps.

Increasing the stats targets for the GROUP BY columns might help,
but I think what's basically going on here is there's correlation
between the GROUP BY columns that the planner doesn't know about.

One thing I'm wondering is why you're grouping by owner_customer_id
and t_fact.provider_id, when these aren't used in the output.

			regards, tom lane