|
Comments
|
|
Pretty informative. Thank you.
|
|
Jamshid Nouri on
6/25/2009
short and informative demo
|
|
|
Though we know lot of operator this and other video gives us a better understanding of the concept and how they are executed in the background. Thank you Sir.
|
|
|
Sorry, in my mind, the description didn't match the title of this item. Interesting background though.
|
|
|
Glad the video was helpful. These short videos seem to be pretty hit or miss.
|
|
Jed Perlowin on
6/25/2009
I was hoping he would compare it to the GROUP BY to see what the differences (if any) are.
|
|
|
Thnks
|
|
|
nicely presented - BUT - a comparison to execution plan for a GROUP BY on the same data would have been quite useful
|
|
Carla Wilson on
6/25/2009
Ah, grasshopper! A good teacher shows the path but lets the student explore!
Ok, so I set up a query using "group by" instead of "distinct", and I got the exact same query plan.
|
|
Carla Wilson on
6/25/2009
er, I should say, execution plan.
|
|
|
Concise and complete
|
|
|
I'm not sure who is the teacher and who is the student in this situation. ;-)
That is interesting that it showed an identical execution plan. What I hoped was the key take-away here is that the DISTINCT operation is an aggregation and therefor, usually expensive.
|
|
|
Its realy good and helpfull. Thanks for that
|
|
|
Simple but good...
|
|
|
Simple but good...
|
|
|
but what if no index covers the columns in the distinct list?
|
|
|
Is there a way to optimize usage of the DISTINCT operator (i.e. is there a way to minimize the cost of the Hash Match (Aggregate) function)?
|
|
|
Since it's an aggregation, it really depends on what you're aggregating. If you have a covering index you could see some performance improvement. But in general, aggregation is expensive and frequently involves extra operations such as the Hash Match in order to arrive at the unique list of data.
|
|
|
It's excellent. Thanks.
|