I mentioned this previously<\/a>, but I’ve been reading “Principles of Distributed Database Systems.” I’m enjoying it, and it’s helping me solidify many of the concepts that I apply daily in my capacity as a Principal BI Solutions consultant. Database theory, and specifically as it relates to tuning is part of any professionals work with Oracle. We’ve all deciphered the performance implications and clues for improvements from EXPLAIN PLAN<\/a>. I’ve always been told you want to be able to give Oracle the clues\/configurations to enable filter of results (selection) before joining. It always made sense but I had never understood fully the concepts behind these recommendations. Until now…<\/p>\n \nI don’t espouse to understand all of the complexities behind these issues but I ran across a great reference chart. I wanted to post it here along with some numbers for demonstration as a quick reference for any professionals with understanding of quadratic, logarithmic, and linear scales to match those up with the operations we use on a day to day basis.<\/p>\n \nThis is from the book mentioned above, however I’m sure it’s rather common knowledge.<\/p>\n
OPERATION<\/strong><\/td>\n| COMPLEXITY<\/strong><\/td>\n<\/tr>\n | SELECT<\/td>\n | O(n)<\/em><\/td>\n<\/tr>\n | PROJECT (without dedup)\t<\/td>\n<\/tr>\n | PROJECT (with dedup) <\/td>\n | O(n*log n)<\/em><\/td>\n<\/tr>\n | GROUP<\/td>\n<\/tr>\n | JOIN<\/td>\n<\/tr>\n | SEMIJOIN<\/td>\n<\/tr>\n | DIVISION<\/td>\n<\/tr>\n | SET OPERATORS<\/td>\n<\/tr>\n | CARTESIAN PRODUCT<\/td>\n | O(n²)<\/em><\/td>\n<\/tr>\n<\/table>\n | A quick look at some numbers in the orders mentioned yield the following “costs” in n operation times.<\/p>\n
|