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
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 |