Re: Is Hash Agg being used? 7.4 seems to handle this query worse than 7.3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Is Hash Agg being used? 7.4 seems to handle this query worse than 7.3
Date: 2003-02-11 19:36:38
Message-ID: 27528.1044992198@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Greg Stark <gsstark(at)mit(dot)edu> writes:
> It was always a bit mysterious to me how postgres could implement
> count(distinct) without introducing a separate sort and aggregate for each
> occurrence.

It can't. There's a sort + uniq + aggregate process done behind the
scenes in the executor for each DISTINCT aggregate. This doesn't show
up on the EXPLAIN output, because the planner has nothing to do with it.

I thought about doing this via a separate hashtable for each group ...
for about a minute. The trouble is you have to run those things in
parallel if you're doing hashed aggregation, so the resources required
are really out of the question in most cases. With the group approach,
the executor is only processing the values for one outer group at a
time, so it only has to run one inner sort + uniq + agg process at a
time.

I suppose we could consider introducing two implementations (hash or
sort/uniq) for a DISTINCT agg within the executor, but it's code that
remains unwritten...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dmitry Tkach 2003-02-11 20:00:13 Re: accessing currval(), How? ... Trigger? I think...???
Previous Message Greg Stark 2003-02-11 19:29:51 Re: Is Hash Agg being used? 7.4 seems to handle this query worse than 7.3