From: Tom Lane <tgl@sss.pgh.pa.us>
To: Samuel Gendler <sgendler@ideasculptor.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: yet another q
Date: Thu, 19 Aug 2010 12:28:23 -0400
Message-ID: <7713.1282235303@sss.pgh.pa.us> (raw)
In-Reply-To: <AANLkTimvgOTbFgaWc8z0irHr+LrObDbbvxR49xSCeNfd@mail.gmail.com>
References: <AANLkTimvgOTbFgaWc8z0irHr+LrObDbbvxR49xSCeNfd@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, sgendler@ideasculptor.com
Subject: Re: yet another q
In-Reply-To: <7713.1282235303@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox