Press "Enter" to skip to content

Author: Kevin Feasel

Using Fabric Data Wrangler for Testing

Published 2026-05-13 by Kevin Feasel

Kristina Mishra checks out some data:

Data Wrangler has been available for awhile now, but I’ll be honest, it’s not something we’ve been actively using. We’ve been heads down on time-sensitive projects for over a year and needless to say, our cup runneth over. Recently we’ve had a bit of respite and I decided to see how we could use Data Wrangler within the context of our current Microsoft Fabric data warehouse (i.e. medallion layer lakehouses).

Data Wrangler has a lot of cool features that will give you code snippets for what you want to do, but I wanted to use it a different way. I wanted to have an easy way to do a quick check for dimension tables. I also wanted an easy-peasy way for others, some of whom are not developers, to be able to do quick sanity check of the data.

Click through to see how it works.

Leave a Comment

Lessons Learned from Change Data Capture

Published 2026-05-13 by Kevin Feasel

Deborah Melkin shares some lessons from working with Change Data Capture:

This has definitely been something that is I’ve had some experience with recently. It inspired my “Change Tracking in SQL Server 2025: Exploring Change Event Streaming vs CDC” session that I presented at SQLCON 26. We had been having problems troubleshooting various issues around Change Data Capture (CDC) and someone suggested that I take look at Change Event Streaming, which is new for SQL Server 2025. One of the great things about putting together sessions like this is that I was able to create a very simple POC to understand it all works. It was also helpful for me to understand some key takeaways with both of these.

The Change Event Streaming lessons are fairly limited (for good reason) but Deb shares some nice tips on working with CDC.

Leave a Comment

Updating the Documentation on Forced Parameterization

Published 2026-05-13 by Kevin Feasel

Brent Ozar shares an update:

I love me some documentation.

For years, I’ve pointed folks to the SQL Server 2008 documentation on Forced Parameterization, a really useful tool for reducing plan cache bloat, getting more accurate reusable query plans, and enabling SQL Server 2019 and 2022’s Intelligent Query Plan features, many of which rely on the same query text coming in repeatedly over time in order to tune it. That documentation was pretty sparse, though.

Click through for a link to the new documentation and what it entails. Some of us gripe about the documentation and some of us fix it.

Me? I sit up in the balcony with Waldorf and laugh.

Leave a Comment

Tracking Record Changes in SQL

Published 2026-05-13 by Kevin Feasel

Andy Brownsword builds a hash key:

The issue: there was no indicator of which records had been modified and as a result the process took way too long, and downstream reporting wasn’t available on time.

After reviewing and stepping through the process it became clear that the vast majority of data didn’t change. This was a daily process handling 12 months of data, yet over 99% had no changes at all. However the process ingested the whole dataset (~250m records) and processed it in SQL.

Click through for an architectural-level discussion. In practice, HASHBYTES() works really well, especially when you use CONCAT() or CONCAT_WS() to put together the columns you care about

Leave a Comment

Tips for Reading an Explain Plan

Published 2026-05-13 by Kevin Feasel

Jamal Hansen has a primer on explain plans for Python developers:

We talked early in this series about SQL being a declarative language. You tell the database what you want, and it figures out how to get it. But we’ve also seen that SQL gives you the freedom to do things in many ways, and some of those ways are more efficient than others.

Sometimes, a slow query means you didn’t choose the most efficient approach. Other times, your data has simply outgrown the default way the database finds records, and you need to give it a little help.

And in a judo move, if you already understand how explain plans work, you can figure out how to perform code profiling in Python.

Leave a Comment

Generated Columns in JSONB in PostgreSQL

Published 2026-05-13 by Kevin Feasel

Richard Yen works with JSONB:

Over the past year, I’ve worked in a handful of contexts managing large volumes of data stored as JSONB in PostgreSQL. The scenario is common: users appreciate the flexibility of a document-oriented storage model, avoiding the need to predefine schemas or constantly migrate table structures as their data requirements evolve. JSONB documents can be deeply nested with numerous optional fields, and they scale to hundreds of kilobytes per record without issue. However, when the time comes to query these documents – filtering by user ID, event type, timestamps, or nested action properties – the queries can become slow and/or cumbersome to work with.

The problem I want to address is: “How do we make searching JSONB data more efficient without breaking apart our documents or forcing it into columns in a relational database?” There are several approaches available in Postgres, each with different tradeoffs. I hope to shed some light on those approaches in this article.

Click through for the demonstration, as well as various trade-offs and caveats.

Leave a Comment

PlanTrace Support for PostgreSQL

Published 2026-05-12 by Kevin Feasel

Eduardo Pivaral has updated a website:

When I built PlanTrace, it was a Redshift-only tool. Paste your EXPLAIN output, get an interactive graph, cost heatmap, and tuning insights — all client-side, nothing stored. It worked well, but Redshift is only part of the picture for most teams.

PostgreSQL is where most development happens, where staging environments live, and where a lot of production workloads run. So I extended PlanTrace to support it — same interface, same zero-friction flow, automatic engine detection.

Click through to see how it works.

Leave a Comment

Building Mermaid Diagrams for Jekyll

Published 2026-05-12 by Kevin Feasel

Thomas Williams builds a visual:

Mermaid https://mermaid.ai/ is “Markdown inspired” diagrams as code. With the diagram defined as text, special/proprietary software isn’t needed to create or edit diagrams. The text defining the diagrams can be edited by anyone – so can be kept up-to-date. Diagrams can also be version controlled, like any other code.

This matters because better diagrams improve documentation, and communication.

I’ve used Mermaid a bit. It’s fairly powerful, though can be tricky if you’re used to a more free-flow diagram design.

Leave a Comment

Writing SQL-Only Extensions for Postgres

Published 2026-05-12 by Kevin Feasel

Shaun Thomas writes an extension:

Recently at Postgres Conference 2026 in San Jose, I presented a talk called Let’s Build a Postgres Extension! Since that entire presentation was primarily focused on writing a C extension while exploring the Postgres source code, I only mentioned pure SQL extensions as an aside. But what’s more likely in the Postgres community in general: C devs, or people who know SQL?

It turns out that you can do a lot with functions, triggers, views, tables, and various other Postgres-native capabilities. The extension system doesn’t care whether the contents are compiled C or plain SQL. It just wants a control file, a SQL script, and an optional Makefile to help with installation.

So let’s build a relatively trivial extension article entirely in SQL.

It’s a fairly neat capability, for sure.

Leave a Comment