Press "Enter" to skip to content

Author: Kevin Feasel

Table Renames and Views in PostgreSQL

Published 2026-01-06 by Kevin Feasel

Deepak Mahto runs into a common issue:

Instead of doing a straight:

ALTER TABLE ... ADD COLUMN ... DEFAULT ... NOT NULL;

we chose the commonly recommended performance approach:

  • Create a new table (optionally UNLOGGED),
  • Copy the data,
  • Rename/swap the tables.

This approach is widely used to avoid long-running locks and table rewrites but it comes with hidden gotchas. This post is about one such gotcha: object dependencies, especially views, and how PostgreSQL tracks them internally using OIDs.

This also happens in SQL Server, though we do have a helpful sp_refreshview procedure that means not needing to drop + recreate views.

Leave a Comment

Tracing Trigger Executions in SQL Server

Published 2026-01-06 by Kevin Feasel

Kendra Little does some investigating:

Triggers can be tricky to observe in SQL Server. When you need to understand exactly what a trigger is doing and what it impacts, Query Store and Extended Events both have something to offer, but using them effectively requires navigating some confusing nuances. Query Store tracks query-level executions aggregated by query_id, but has a habit of generating a lot of query_ids with different context settings for triggers. Extended Events can capture trigger module starts and individual statement completions within triggers.

This post walks through setting up both observation methods on a test trigger, then compares what each one shows. You’ll see how Query Store data gets spread across multiple query_ids and context_settings_id values, a variety of ways to trace triggers in XEvents, and why the numbers don’t always match up exactly between traces and Query Store.

This is definitely worth the read. Kendra does a great job laying things out in a thoughtful manner and provides a lot of additional insight.

Leave a Comment

JSON Data and Columnstore Indexes

Published 2026-01-06 by Kevin Feasel

Niko Neugebauer continues a series on columnstore:

Not since SQL Server 2008 that Microsoft has added a new base data type to SQL Server, but in SQL Server 2025 they have added not 1 but whole 2 new data types – Vector and JSON. The first one (Vector) and the corresponding index (Vector Index) are described in details in the Columnstore Indexes – part 134 (“Vectors and Columnstore Indexes”) and this post is dedicated to the new JSON data type and the new JSON Index and their compatibility with the Columnstore Indexes and the Batch Execution mode.

One common trait for the Vector & JSON Indexes is that both come with a big number of limitations and they are all enabled under a “Preview” option, making them unsuitable for the most production environments.

Niko has a somewhat-humorous and somewhat-infuriating table at the beginning describing just how much support columnstore indexes have for JSON data types.

And it is another example of the frustrating way in which Microsoft will release something before it’s even half-baked, demand consumer adoption to continue working on it, and then can the feature because people can’t use the not-even-half-baked feature in its current state. There’s a fine line between rapid prototyping and quick market feedback versus strangling products in the crib, and I think they’re pretty far onto the wrong side of things when it comes to most SQL Server functionality.

Leave a Comment

From Conjecture to Hypothesis and the Failure of Data-Driven

Published 2026-01-06 by Kevin Feasel

Alexander Arvidsson does some research:

I’ve spent the last few weeks diving deep into something that’s been bothering me for years. Everyone talks about being “data-driven,” but when you actually look at what that means in practice, something doesn’t add up. Companies are knee-deep in data, wading in dashboards, drowning in reports, and yet… nothing changes.

So I went looking for examples. Real examples. Not “we implemented analytics and it was amazing” marketing fluff, but concrete cases where data actually improved outcomes. What I found was fascinating, and not at all what the analytics vendors want you to hear.

This is an interesting article and starts to get to the reason why “data-driven” companies fail to deliver on their promise. It also gets to one of my nag points around dashboards: the purpose of a dashboard is to provide relevant parties enough information, at a glance of the dashboard, to take whatever action is necessary. In order to develop a good dashboard, you need to understand all of that information: who the relevant parties are, what decision points exist, under what circumstances should an individual take action, and (ideally) what action the individual could take. But that’s a lot of information and a lot of effort to tease out the right answers.

Leave a Comment

Data Corruption in PostgreSQL

Published 2026-01-06 by Kevin Feasel

Josef Machytka explains a new (for PostgreSQL) solution to an old problem:

PostgreSQL 18 made one very important change – data block checksums are now enabled by default for new clusters at cluster initialization time. I already wrote about it in my previous article. I also mentioned that there are still many existing PostgreSQL installations without data checksums enabled, because this was the default in previous versions. In those installations, data corruption can sometimes cause mysterious errors and prevent normal operational functioning. In this post, I want to dissect common PostgreSQL data corruption modes, to show how to diagnose them, and sketch how to recover from them.

Read on to learn more, as well as what this new change means.

Leave a Comment

An Overview of SQL Database in Microsoft Fabric

Published 2026-01-06 by Kevin Feasel

Rebecca Lewis shares some thoughts:

Now let’s look at an actual transactional database running inside Fabric.

SQL database in Microsoft Fabric became generally available at Ignite in November 2025. This isn’t a data warehouse. It’s not a lakehouse with a SQL endpoint. It’s a real OLTP database — based on the same engine as Azure SQL Database — designed for operational workloads, running as a fully managed SaaS service inside your Fabric capacity.

Read on for some thoughts around capabilities and current limitations.

Leave a Comment

Releasing a tSQLt Test Adapter for VS2022 and Later

Published 2026-01-05 by Kevin Feasel

Ed Elliott has been busy:

I have had a number of requests for me to update the tSqlt Test Adapter over the years so it would work with more recent versions of Visual Studio. I finally got around to doing this and I am pleased to say that the new version works with VS 2022, 2025 and should continue to work in future releases.

Between Visual Studio 2017 and 2019 the changes required were minimal but between 2017 and 2022 the changes meant a rewrite of the test adapter visual studio integration parts which meant it wasn’t a simple change.

Read on for information on how to install and use the extension.

Leave a Comment

Split Screens in SSMS

Published 2026-01-05 by Kevin Feasel

Greg Low has a large monitor:

If you are working with really long script files in SSMS, you might need to work on more than one part of the script at the same time. Perhaps you need to work on a function, and also on the code that calls the function.

Click through for a short-but-sweet demonstration. I rarely used split screen in SSMS, but it is nice for comparisons or viewing two parts of a file at the same time.

Leave a Comment

Diagnosing DirectQuery Performance Woes

Published 2026-01-05 by Kevin Feasel

Chris Webb digs into one type of DirectQuery performance slowdown:

One very common cause of Power BI performance problems is having a table with a large number of rows on your report. It’s a problem I wrote about here, and while I used an Import mode for my example in that post I also mentioned that this can be an even bigger problem in DirectQuery mode: while the DAX query for the table visual might have a TOPN filter that asks for 502 rows, the query going back to the DirectQuery data source (usually a SQL query) may not have that filter applied and could return a much larger number of rows, which could then take a long time for Power BI to read. I wrote about this in more detail here and showed how you can diagnose the problem in Performance Analyzer by looking at the Execute DirectQuery event and ActualQueryDuration, RowsRead and DataReadDuration metrics. But now I have a custom visual to display Performance Analyzer export data, what does this look like? Also, what can Execution Metrics tell us?

Read on to learn more.

Leave a Comment