Greetings, data enthusiasts!
Our June meeting is scheduled for Monday, June 10th, at 5:30 pm! We will meet in person at: Rensselaer Chamber of Commerce, 90 4th Street, Troy, NY.
Please RSVP at https://www.meetup.com/capital-area-sql-server-user-group/events/297521906/ if you are attending, so we can purchase an appropriate amount of food for everyone. Food is TBA (will be announced closer to the event). For this meeting, we are welcoming Taiob Ali to join us from the Boston area. Thank you Taiob for taking the drive out to the Capital Region to be with us!
Our meeting schedule is as follows:
- 5:30 PM: Food, soft drinks, and networking
- 6:15 PM: Chapter news and announcements
- 6:30 PM: Presentation
We usually wrap up between 7:30 PM and 8:00 PM.
This month, Taiob Ali is presenting an excellent topic for both beginners and more advanced data professionals: "Think Like the Cardinality Estimator"
SQL Server uses a phase during query optimization, called cardinality estimation (CE). This process makes estimates based on the statistics as to how many rows flow from one query plan iterator to the next. Knowing how CE generates these numbers will enable you to write better TSQL code and in turn, influence the type of physical operations during query execution. Based on that estimated rows, the query processor decides how to access an object, which physical join to use, and how to sort the data. Do you know how the CE generates these numbers? If your query has only one predicate, the query optimizer will use the histogram to estimate how many rows will be qualified. What happens when you have multiple predicates, range predicates, variable values that are “NOT KNOWN” to the optimizer, or you have predicate values increasing in ascending order? Do you know what will happen if your predicate is using an amount that is outside of the histogram range?
In this session, I will show you how the cardinality estimator estimates in all of these scenarios. You will walk out of this session with a clear understanding of how the CE generates its numbers and is ready to tackle those nasty, hard-to-solve query plans.