A Fine Slice Of SQL Server
Osheen MacOscar makes a function faster:
The way it is currently written is how any normal for loop will run, where the current iteration must finish before the next one starts. With this code we shouldn’t need to wait for the previous API call, there is no dependency or anything like that. In theory we could run all of the individual player queries at once and the function would be a lot faster.
Read on to see how.
Leave a CommentValerie Junk creates a visual:
In this tutorial I want to show a fun little trick in Power BI. We are going to create a lollipop visual. And yes, I am still searching for a strong business case, but it is a very nice visual and the steps you take to build it can help in many other situations.
If you want to show trends without focusing too much on exact numbers, this visual works surprisingly well. And the best part is that you can build it with the standard line chart.
Read on to see how.
Leave a CommentTomaz Kastrun has been busy with this year’s advent of SQL Server 2025 blog posting. Catching up, Tomaz first looks at base-64 encoding and decoding:
SQL Server 2025 introduces a new T-SQL functions for BASE64 varbinary expressions. The first function returns base64-encoded text (BASE64_ENCODE() ), respectively for BASE64_DECODE().
BASE64_ENCODEconverts the value of a varbinary expression into a base64-encoded varchar expression.
BASE64_DECODEconverts a base64-encoded varchar expression into the corresponding varbinary expression.
I really like this, by the way. Base-64 encoding is quite useful for web transmissions, so having a place to generate that output easily is nice.
SQL Server 2025 introduces a new T-SQL functions for Regular Expressions (RegEx).
With multiple RegEx functions, the LIKE function indicates if the regular expression pattern matches the string or is in a string. The function is REGEXP_LIKE() that will do the job.
And third, we have REGEXP_SUBSTR() and REGEXP_REPLACE():
Continuing with SQL Server 2025 T-SQL functions for Regular Expressions for replace and substring functionalities.
Click through for Tomaz’s thoughts on all five of these functions.
Leave a CommentTo be fair, humans might do the same thing and over-react, but mostly we become hesitant with unexpected news. That slowness can be an asset. We often need time to think and come to a decision. Lots of our decisions aren’t always based on hard facts, and a lot of business isn’t necessarily fact driven either. We often put our thumb on the scales when making decisions because there isn’t a clear path based on just data.
Steve’s thrust is about AI but I want to riff on “real-time” in general. First, my standard rant: “real-time” has a specific meaning that people have abused over the years. Fighter pilots need real-time systems. The rest of it is “online.” For a hint as to the difference: if you’re okay waiting 100ms for a response due to network delays or whatever else, that’s not real-time.
Standard rant aside, “I need to see real-time data” is a common demand for data warehousing projects. I worked on a warehouse once where the business wanted up-to-the-minute data but our incoming data sources for cost and revenue information refreshed once a day per customer and intraday information was sketchy enough that it didn’t make sense to store in a warehouse. But when you probe people on how often they’ll look at the data, it turns out that hourly or daily loads make more sense based on the review cadence.
The question to ask is, how big is your OODA loop and is additional information really the limiting factor? Sometimes that answer can be yes, but generally there are other factors preventing action.
Leave a CommentAfter spending some time thinking about the best way to come back to writing about Columnstore Indexes, after 5 and half years hiatus, I came to a conclusion that I have never published a post on what is still missing. With that in mind, I decided to mark my comeback to writing technical posts on my blog with rather simple post on the things that are needed, but did not made into the SQL Server – based engines so far (as of December 2025).
Niko has seven items on his list. I tend not to cover wish lists on Curated SQL, but when it’s Niko and columnstore indexes, I’m willing to make an exception.
Leave a CommentElizabeth Christensen has some neat imagery:
The secret to unlocking performance gains often lies not just in what you ask in a query, but in how Postgres finds the answer. The Postgres
EXPLAINsystem is great for understanding how data is being queried. One of secretes to reading EXPLAIN plans is understanding the type of scan done to retrieve the data. The scan type can be the difference between a lightning-fast response or a slow query.
Click through for the list, as well as images that clearly explain what’s happening.
Leave a CommentRebecca Lewis has a two-parter. First up is a post covering the guard rails available in IQP:
When Microsoft introduced Intelligent Query Processing in SQL Server 2019 and expanded it in SQL Server 2022 and 2025, the message was simple: upgrade, enable the right compatibility level, and the optimizer will quietly make your queries faster. Features like batch mode on rowstore, memory grant feedback, scalar UDF inlining, and parameter-sensitive plan (PSP) optimization all promise “automatic performance.”
But buried in Microsoft’s documentation is a reality worth understanding: Some IQP features can reduce or discontinue feedback when performance becomes unstable. This is intentional. IQP includes guard rails—safety mechanisms that change or stop certain feedback behaviors if they prove counterproductive.
Part two tells us how to figure out if an IQP feature got the works:
Memory Grant Feedback was introduced in SQL Server 2019 and enhanced in SQL Server 2022+. Microsoft documents several plan attributes that reveal how the engine adjusted or suspended feedback. These attributes appear under the MemoryGrantInfo node in the execution plan.
And stay tuned for part three.
Leave a Comment