| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Markus Schaber <schabios(at)logi-track(dot)com> |
| Cc: | PostgreSQL Performance List <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Multiple Uniques |
| Date: | 2004-09-02 14:22:37 |
| Message-ID: | 19516.1094134957@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Markus Schaber <schabios(at)logi-track(dot)com> writes:
> Today, we stumbled about the following query plan on PostGreSQL 7.4.1:
> logigis=# explain select count(id) from (select distinct id from (select distinct ref_in_id as id from streets union select distinct nref_in_id as id from streets) as blubb) as blabb;
> I was somehow irritated by the fact that the Query Plan contains 4 Uniques.
Well, if you write a silly query, you can get a silly plan ...
As you appear to have realized later, given the definition of UNION,
all three of the explicit DISTINCTs are redundant.
> So, now my question is, why does the query optimizer not recognize that
> it can throw away those "non-unique" Sort/Unique passes?
Because the issue doesn't come up often enough to justify expending
cycles to check for it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2004-09-02 19:33:38 | Re: Multiple Uniques |
| Previous Message | Markus Schaber | 2004-09-02 13:43:40 | Multiple Uniques |