| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
| Cc: | "Ron Mayer" <rm_pg(at)cheapcomplexdevices(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Why are distinct and group by choosing different plans? |
| Date: | 2007-08-03 00:48:07 |
| Message-ID: | 17521.1186102087@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> I think "distinct" just doesn't know about hash aggregates yet. That's partly
> an oversight and partly of a "feature" in that it gives a convenient way to
> write a query which avoids them. I think it's also partly that "distinct" is
> trickier to fix because it's the same codepath as "distinct on" which is
> decidedly more complex than a simple "distinct".
It's not an oversight :-(. But the DISTINCT/DISTINCT ON code is old,
crufty, and tightly entwined with ORDER BY processing. It'd be nice to
clean it all up someday, but the effort seems a bit out of proportion
to the reward...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Carlos H. Reimer | 2007-08-03 01:47:25 | RES: RES: Improving select peformance |
| Previous Message | Gregory Stark | 2007-08-02 22:37:43 | Re: Why are distinct and group by choosing different plans? |