Paul White (@SQL_Kiwi) is an independent SQL Server technical consultant with 20 years experience, specializing in performance tuning the SQL Server Core Engine, and is well known for his expertise in execution plans, the query processor, and the query optimizer. Currently living in New Zealand, Paul writes the SQL Server internals blog Page Free Space.
Over the years, Paul has worked internationally on a number of high-volume critical systems where ultimate performance and reliability were the primary goals. A SQL Server MVP since 2011, he contributes regularly to a range of web sites and forums, including Database Administrators Stack Exchange. Paul has also spoken at a variety of user groups and community events such as SQL Saturdays and the annual SQL Pass Summit.
Paul White (@SQL_Kiwi) demonstrates another case where a cursor might be the most efficient approach to solving a typically set-based problem: medians.
Paul White (@SQL_Kiwi) concludes his two-part series on SQL Server sort internals, including two new classes specific to In-Memory OLTP in SQL Server 2014.
Paul White (@SQL_Kiwi) rolls up his sleeves in his usual way, showing off the debugger several times while explaining the internals of SQL Server sorts.
With detailed information and his uncanny knack for explaining technical concepts very well, Paul White (@SQL_Kiwi) concludes his series on ACID, transactions, and isolation levels in SQL Server with a great read on READ UNCOMMITTED.
Paul White (@SQL_Kiwi) follows up on his thorough breakdown of indexed view maintenance with the details of a bug that can render an indexed view incorrect.
Paul White (@SQL_Kiwi) explains various ways SQL Server makes runtime decisions about whether to use the b-tree structure or perform allocation order scans.
Paul White (@SQL_Kiwi) demonstrates performance tuning a SQL Server execution plan as a whole, instead of honing in too narrowly on individual operators.
Paul White (@SQL_Kiwi) talks about coercing the optimizer into avoiding sorts, reminding us that sound indexing should still be our first line of attack.
Paul White (@SQL_Kiwi) looks at a couple of cases where – even though T-SQL is supposed to be a declarative language, and any query that uses the same logic and same semantics should ultimately lead to the same plan and comparable performance – rewriting queries can change the plan in dramatic ways.
Paul White (@SQL_Kiwi) details a regression bug in RCSI caused by a fix for a different bug. If you are running SQL Server 2008 R2, you should read this.
