"Jeffrey W. Baker" <jwbaker@acm.org> writes:
> On Sat, 2006-01-28 at 10:55 -0500, Tom Lane wrote:
>> Assuming that "month" means what it sounds like, the above would result
>> in running twelve parallel sort/uniq operations, one for each month
>> grouping, to eliminate duplicates before counting. You've got sortmem
>> set high enough to blow out RAM in that scenario ...
> Hrmm, why is it that with a similar query I get a far simpler plan than
> you describe, and relatively snappy runtime?
You can't see the sort operations in the plan, because they're invoked
implicitly by the GroupAggregate node. But they're there.
Also, a plan involving GroupAggregate is going to run the "distinct"
sorts sequentially, because it's dealing with only one grouping value at
a time. In the original case, the planner probably realizes there are
only 12 groups and therefore prefers a HashAggregate, which will try
to run all the sorts in parallel. Your "group by date" isn't a good
approximation of the original conditions because there will be a lot
more groups.
(We might need to tweak the planner to discourage selecting
HashAggregate in the presence of DISTINCT aggregates --- I don't
remember whether it accounts for the sortmem usage in deciding
whether the hash will fit in memory or not ...)
regards, tom lane
