Press "Enter" to skip to content

Curated SQL Posts

Merging Data into a Fabric Lakehouse via Python Notebook

Published 2026-07-10 by Kevin Feasel

GIlbert Quevauvilliers uses a pure Python notebook:

In this blog post I am going to show you how to use a Fabric Python runtime notebook (This is the notebook which only uses Pure Python functions and consumes significantly lower Capacity Units (CUs)).

The pattern is how to get new data and merge it into an existing Lakehouse table. This ensures that if the notebook is run again data will not be duplicated.

Why I am sharing this is I have found that there is not a lot of useful information about how to use a Python notebook to write to a lakehouse table easily. And then also how to use a Merge statement making it easier to insert or update your lakehouse tables. This simplifies the ingestion process, runs faster and consumes the least amount of CUs

Gilbert doesn’t mention it in the blog post but the notebook does use DuckDB to query the data using SQL.

Leave a Comment

Partition Pruning on Non-Partitioned Columns in PostgreSQL

Published 2026-07-10 by Kevin Feasel

Haki Benita does a bit of pruning:

One of the most valuable things about partitioned tables is pruning – the database’s ability to eliminate entire partitions based on a query predicate. Under conventional wisdom, pruning can only be achieved when querying by the partition key – this makes choosing the right key extremely difficult. However, if your data follows certain patterns, using some clever tricks you can achieve pruning even when filtering by non-partition key columns.

In this article, I demonstrate how to achieve partition pruning when filtering by non-partition key columns.

Click through to see how.

Leave a Comment

Two Pain Points in SQL Server Code

Published 2026-07-10 by Kevin Feasel

Steve Jones digs up a pair:

There are two things that immediately stand out to me when I see a query and create concern.

  1. cross joins
  2. functions in the where/on clause

While there are other things I might see, these two stand out and usually I can guess there will be issues.

Steve specifically calls out ANSI-89 style joins, which are awful. Before continuing, I agree with Steve’s points, but I figure I’d do a “yes, and” for this one.

When it comes to cross joins, there are specific circumstances in which I’ve written cross joins to great effect. The one that comes to mind most readily is when I need to create the raw data that will let you generate a matrix in a reporting tool.

Let’s say you want to know, for each sales territory and month, the number of new customers that month, the prior month, and the next month. The LAG() and LEAD() functions only work on rows, not intervals. Therefore, LAG() on the July row will show you the row prior to July. That might be June or it might be March, depending on how much data you have.

The solution, then, is to get the full set of months you care about from, say, a calendar table. Then, get the full set of sales territories. Cross join those two and you’ll have the entire range of relevant data. You can then left outer join to the actual data and fill in the gaps.

I have an example of this as a demo script on my Analyzing Business Data with T-SQL talk.

Leave a Comment

Red Flags in Query Design

Published 2026-07-09 by Kevin Feasel

Thomas Williams has a list:

Nowadays I look after 3rd-party databases more than internally-developed ones, so I accept there’s a whole lot of ex-best practices, vendor preferences, and possibly shortcuts in queries I might come across – whether it’s a poorly-performing query, a blocker, or an error.

(Although, when I developed software more frequently, I was guilty of all the gripes below. My start in SQL, last century, was poring over a big yellow “For Dummies” book. I was the dummy.)

Click through for the list. I particularly hate tibbling, a rather derisive term for the malformed version of Hungarian notation. This would just lead me down a rant about how systems Hungarian notation was a mess, whereas apps Hungarian notation can be useful in certain circumstances. Tibbling provides no semantically valuable information, which is why I dislike it so much.

Leave a Comment

JSON Index Testing in SQL Server 2025

Published 2026-07-09 by Kevin Feasel

Reitse Eskens gives it a whirl:

In today’s cloud era, Azure SQL is usually first with new functionality, while on-premises SQL Server follows. One of the new things is the JSON data type and accompanying JSON index.

Because I had to learn how JSON works in SQL Server for my DP-800 exam, I decided to see how the JSON index works and when it works. I’ll go into the execution plans, some details, and check out the statistics when a query runs. Just so you know, this is much deeper than the certification requires, so no need to get this all in your head for the exam.

Click through for a rundown of how this feature works on-premises and what you should be on the lookout for.

Leave a Comment

Solving the Maximum Flow Problem in T-SQL

Published 2026-07-09 by Kevin Feasel

Sebastiao Pereira implements the Ford-Fulkerson algorithm:

Graphs can be used to formulate mathematical models for many different applications and one particular type of problem to be solved deals with networks that transport some kind of resource from one endpoint to another, like water or electricity. Is it possible to create using only SQL Server features?

What’s neat about this is that this sort of flow algorithm also works for, say, complex ETL processes. Also, in case you were as curious as I was, that map is Dresden.

Leave a Comment

T-SQL Code Smells

Published 2026-07-09 by Kevin Feasel

Rob Farley has a few:

I feel like I should preface this with a disclaimer. I added “potentially-” to the title, because there are many queries that might seem bad but can actually perform just fine. There are queries that on the surface can be great, but are nasty without a particular index, and there are queries that make me cringe a little when looking at them, but are actually okay. Brent Ozar is asking about signs of bad code for this month’s T-SQL Tuesday (the 200th – and I have a response for all 200 if you look back through my history of posts), and he wants us to write this for 2004 Brent, rather than 2026 Brent.

Click through for what Rob has come up with. I agree with all of Rob’s examples and do appreciate his usage of the APPLY operator as a way of solving one common problem.

Leave a Comment

The Never-Ending Query

Published 2026-07-09 by Kevin Feasel

Andy Yun doesn’t like it:

You know THE ONE I’m talking about… it has numerous sub-queries and CTEs… JOIN after JOIN after JOIN… predicates within predicates. Or maybe it’s just an obscene MERGE statement. 

These are particularly painful to deal with because it’s hard to test the pieces in isolation and ensure that an issue earlier in the process doesn’t bite you later.

Leave a Comment