Press "Enter" to skip to content

Author: Kevin Feasel

Applying Color Thoughtfully

Published 2026-08-14 by Kevin Feasel

Amy Esselman provides some guidance:

One of our top tips for explanatory communications is to use color sparingly and purposefully to help your audience understand your data and message. Color should be an explicit choice, not something your software applies by default, whether that’s a graphing tool or an AI assistant generating your first draft. These tools can build a chart in seconds. They might even add highlighting on their own. But they don’t know which data matters most to your audience. That call is still yours. Used thoughtfully, color is often one of the quickest ways to improve a graph.

Color is an extremely powerful pre-attentive attribute, meaning that it’s something we intuitively see and respond to without explicit thought. That’s why choosing what to color can be so powerful. If everything has bright, distracting colors, you lose an avenue to guide the viewer’s eye. But Amy’s example is a good one to show the particular element(s) in the visual that you want people to focus on, and the viewer’s eyes will automatically go there.

Comments closed

The Value of TRY_PARSE()

Published 2026-08-14 by Kevin Feasel

Steve Jones answers a question:


Someone asked why I would use TRY_PARSE after I posted a question at SQL Server Central: Getting the Average. Isn’t is slower?

A fair question. This quick post looks at why.

I’d use TRY_CAST() or TRY_CONVERT() in this particular scenario. The main reason I’d use TRY_PARSE() would be if you need .NET-specific parsing functionality, such as parsing dates by a specific locale. The reason is that PARSE() and TRY_PARSE() are an order of magnitude slower than their CAST() and CONVERT() cousins.

That said, Steve’s example reminds me of a PolyBase demo I used to do, in which I took a CSV of North Carolina populations by county and read in the information. In that particular dataset, they would use the letter “A” to describe either “Not enough people to show an answer without potentially violating PII” or “We don’t know what the answer is.” So even though it was clearly a numeric attribute in “Population,” the output process overloaded the definition of that attribute and the only way you would know is to happen to see the three rows in ~1500 that happened to have an A in the column value.

Comments closed

Diagnosing High-Cardinality Workloads in Postgres

Published 2026-08-14 by Kevin Feasel

Ryan Booz has a video:

In Part 6 of this special Postgres in Production deep dive series, Ryan Booz asks a question that determines how useful pg_stat_statements can be for you at all: do you have a high cardinality workload? This episode covers what that actually means, why ORMs, dynamic SQL, and AI-assisted development tools generate more unique queries than you might expect, a side by side demo of the same workload on Postgres 17 and Postgres 18, and the concrete checks that tell you whether pg_stat_statements is losing the data you need for query tuning.

Click through for the video and transcript.

Comments closed

Configuring OneLake Security for a Microsoft Fabric Lakehouse

Published 2026-08-14 by Kevin Feasel

Gilbert Quevauvilliers locks things down:

In this blog post, I will show you how to configure OneLake security for a Microsoft Fabric Lakehouse. We will remove the default broad-access role, grant the required Lakehouse access, configure object-, row-, and column-level security, and test the results. The goal is to create a secure-by-default setup in which users can access only the data they need.

Click through for the guide.

Comments closed

The Good, the Bad, and the Ugly of Temp Tables

Published 2026-08-14 by Kevin Feasel

Andy Levy answers a question:

As with almost everything in SQL Server, there is no one-size-fits-all answer when it comes to temp tables. There are times where temp tables have rescued a query, and others where they’ve just caused trouble. And then there’s the times where you’re just scratching your head.

Can you use a CTE or a derived table in place of a temp table? In many cases, yes! But it doesn’t always work out well. When things get particularly complex, the SQL Server optimizer can struggle to find a good plan that doesn’t involve lots of table scans.

Read on for Andy’s thoughts.

Comments closed

The Temp Table of Last Resort

Published 2026-08-13 by Kevin Feasel

Louis Davidson shares an approach:

Temp tables fit into my query writing process as one of those last ditch efforts to make a query execute fast enough. Of course it would have been harder if I had followed all the rules and added a lot of test cases, but I had a pretty busy week last week and am finishing this pretty late on Tuesday night, so I just gave my opinions.

I like Louis’s strategy. It’s easy to add a lot of complexity to queries out of habit, to micro-optimize performance, or because of a meandering thought process. But many times, taking a step back to think about what could make a query simpler will be helpful.

One thing I’ll cover that Louis didn’t touch on is that performance level is (or should be) a requirement. If you have a query running millions of times a day on a system, then yes, it makes sense to squeeze out every microsecond. But for an ELT job that finishes in 20 minutes and where you have a 6-hour window to get the data loaded, shaving five minutes off of the query’s runtime isn’t that important, especially if you’re in read-committed snapshot isolation or using another form of optimistic concurrency.

This is why I recommend starting with simple and only moving to more complex solutions when you need them. Now, do I always follow my own advice? Err…well, the sign pointing to Boston doesn’t have to go there itself…

Comments closed

The Yin and Yang of Temp Tables

Published 2026-08-13 by Kevin Feasel

Deborah Melkin covers the gamut:

My stance is that temp tables are a useful tool when properly used, but they’re very easy to misuse to the point of creating problems. Table variables are even more misused for similar reasons; that could be a whole other blog post that almost starts and ends with “they’re not variables stored in memory but just regular temp tables without stats.”

Click through for examples in which temp tables have been quite helpful, and cases in which temp tables have been actively harmful.

Comments closed

Deletion and Ghost Cleanup in SQL Server

Published 2026-08-13 by Kevin Feasel

Martyn Jones hunts down the ghosts:

The concepts discussed in the previous blog post can also be seen in the transaction log. The logical removal of rows (by marking them as ghost records), the associated allocation metadata updates, and the eventual physical removal of those rows by the ghost cleanup process are recorded as individual transaction log operations.

The demo code uses the undocumented function fn_dblog(), this provides a clear view of the internal sequence of events that SQL Server performs during a delete operation so the individual physical changes required to implement ghosting, and later, cleanup can be studied.

Click though to see how SQL Server marks ghost records, tracks where they are, and performs cleanup.

Comments closed

Comparing Temp Tables to Table Variables

Published 2026-08-13 by Kevin Feasel

Marlon Ribunal compares two techniques:

For this post, I needed to do some research because there is more to #temp tables than simply creating one and using it. As I started digging into the topic, I realized there are a lot of discussions around #temp tables and @table variables, especially around when one might be a better choice over the other.

One of the common arguments is that #temp tables go to disk while @table variables stay in memory. Another argument is that this is a myth. That got me curious about what the actual differences are and when they really matter. Discussions like this almost always starts with where the data is stored (disk vs memory).

Yeah, the “table variables are just in memory” is a myth, at least for normal table variables. Memory-valued user-defined table types do change things, as they don’t use tempdb. But they come with their own set of handcuffs.

Comments closed

Digging into Postgres Plan Caching

Published 2026-08-13 by Kevin Feasel

Jordan Boich runs an experiment:

In my last post, I talked about how I was amazed that PostgreSQL doesn’t have a shared plan cache like SQL Server does. I wanted to create an experiment / lab where I could see this in action, so I built one. I’m going to be leveraging a free PostgreSQL database hosted on an Azure Flexible Server. I’ll also be using DBeaver to connect to my PG Database.

Click through to see what Jordan learned.

Comments closed