Press "Enter" to skip to content

Month: December 2025

New T-SQL Functions

Published 2025-12-08 by Kevin Feasel

Tomaz 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_ENCODE converts the value of a varbinary expression into a base64-encoded varchar expression.

BASE64_DECODE converts 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.

Second up is REGEXP_LIKE():

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 Comment

Thoughts on “Real-Time Decisions”

Published 2025-12-08 by Kevin Feasel

Steve Jones is skeptical:

To 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 Comment

What’s Missing in Columnstore Indexes

Published 2025-12-08 by Kevin Feasel

Niko Neugebauer has a list:

After 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 Comment

Scan Types in PostgreSQL

Published 2025-12-08 by Kevin Feasel

Elizabeth 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 EXPLAIN system 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 Comment

When IQP Features Make Things Worse

Published 2025-12-08 by Kevin Feasel

Rebecca 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

Optimized Locking Slowdowns in SQL Server 2025

Published 2025-12-05 by Kevin Feasel

Rebecca Lewis points out when optimized locking fails:

SQL Server 2025 introduces a feature called Optimized Locking, designed to reduce blocking across read–modify workloads. In many environments it helps, but certain mixed workloads experience longer lock waits, stalled S → U → X transitions, and even occasional threadpool saturation.

My inner 12-year-old has already made about a half-dozen plays on the phrase “When optimized locking SUX.”

Leave a Comment

Comparing TRANSLATE() and REPLACE()

Published 2025-12-05 by Kevin Feasel

Louis Davidson is lost in translation:

The data I am working with sometimes has people with multiple parts to their name (Mary Jo, Cindy Lou) etc, or sometimes Fred/Joe, Mary and Jack, Mary & Jack, or what have you. My goal was to turn these names into little delimited lists that I could parse on a space character with STRING_SPLIT and there were a “few” of these cases. This was the code I had arrived at when I reached the “good enough” stage of my coding.

Louis had 19 nested REPLACE() calls, but Certified Good Guy Erik Darling shows him the way.

Leave a Comment

Sending E-Mails from Data Factory Pipelines

Published 2025-12-05 by Kevin Feasel

Andy Brownsword glues together a few resources:

Not all pipelines in Azure have native options for sending emails. The lucky Fabric folks have an Office 365 connection ready to rock. Data Factory and Synapse don’t have email capability built-in and need another option to send messages. So for everyone who wants more emails for their inbox rules to handle (delete), we’ll build and call a Logic App.

For this example we’ll have basic email parameters – To, Subject, Body – along with an optional attachment from a storage account. Also note that I’ve left all actions with their default names – if you change them make sure to update expressions accordingly.

Read on to see how it all works.

Leave a Comment

Thoughts on Renaming sa

Published 2025-12-05 by Kevin Feasel

Andreas Wolter asks, what is in a name?

This is another one of those subjects that keep circulating: should you rename your sa account?

Plenty of “security check” scripts swear you should. Meanwhile, when you talk to actual humans in the real world, you’ll notice that almost nobody does it. (Funny how that works.)

So what does Sarpedon Quality Lab® recommend – and why? Our answer (read to the end) may surprise you.

Before reading Andreas’s post, I wanted to note that, when I was a DBA and had control of such things, I would actually rename the sa account and then create a separate account called “sa” with zero permissions, not even the ability to connect. I never considered it a critical part of a security posture, but knowing how many scripts try to brute-force an account called sa, I figured setting up a false front like that would add some protection on the margin.

After reading Andreas’s post, I wasn’t aware that doing so would break replication, though it makes sense because I wasn’t using replication at that time. Making sa’s password extremely long is also a good idea.

Leave a Comment