Press "Enter" to skip to content

Author: Kevin Feasel

A Bug in a Frameless Window Aggregate

Hugo Kornelis digs into an execution plan:

The OVER clause, that can be added to aggregate functions to turn them into window aggregates, can come with or without a frame specification, in the form of an ORDER BY clause, plus an explicit or implied ROWS or RANGE clause. If there is no frame specification, then every row in a partition, or window, can see all other rows in the same partition or window for the purpose of the aggregation.

In plansplaining part 6, I looked at this specific form of window aggregation, and explained in detail all the steps that the execution plan takes to compute the aggregation result and add it to each of the rows, for every row in each window.

Click through for another look at the plan.

Leave a Comment

The Case for Foreign Key Constraints

Greg Low violates Betteridge’s Law of Headlines:

Foreign keys are used to ensure referential integrity in relational databases. We don’t want to have orders for customers that don’t exist, or have lines on the orders that refer to products that don’t exist. That seems straightforward enough – and a good idea – so why is there an endless discussion in the development community about whether databases should include declared foreign key constraints or not?

I tend to be a foreign key extremist, in that I want key constraints whenever possible. There are certain specific cases in which foreign key constraints can’t work, but I’d argue they’re much rarer than people think.

Leave a Comment

Connection Recency in Fabric REST APIs

Ryan Adams explains a concept:

Connections are shared infrastructure in Microsoft Fabric. Pipelines, dataflows, semantic models, and other Fabric items use them to reach data sources without storing connection details and credentials in every item. Connection Recency adds the context administrators need to understand how each connection is being used. If you go to “Manage Connections and Gateways” in Fabric settings and open the settings of any connection, the following information card will populate:

Click through to learn more about connection recency and how it can be helpful to understand the mechanic.

Leave a Comment

Delays on Postgres 19

Elizabeth Garrett Christensen digs into some details:

Postgres 19 won’t make the expected release date. PostgreSQL has shipped its major version every fall for the last several years. But this year, the code is in a heavy review cycle, major features have been reverted during beta, and many others are under heavy revision. Beta 4 is scheduled for Sept. 24, 2026. A release of Postgres 19 is certainly delayed by weeks and maybe even months.

Postgres 19 was an ambitious release already, with a lot of large features. With any project, you have to choose priorities. For Postgres, the priorities were quality, followed by shipping within the time window. The team is reducing the scope of the release to get closer to meeting its timeline with the quality it requires.

We can see that Postgres 19 is a rather ambitious release, and Elizabeth includes a list of things that might not make it immediately.

Christophe Pettus also provides some historical context:

PostgreSQL 18 had its first release candidate on September 4, 2025, and went GA three weeks later. As I write this, on September 14, 2026, PostgreSQL 19 has no release candidate date. It has a fourth beta scheduled for September 24, a commit freeze for that beta on September 19, and a stated goal of GA “by the end of October.” In the last three weeks it has lost two of the features that headlined every “what’s new in 19” post written since June, including mine. On August 31, Bruce Momjian wrote on -hackers that “it feels we are in an unprecedented situation here.” A week later, Joshua Drake proposed moving the release to spring 2027. Nobody took him up on it. Nobody laughed, either.

This is not a “PostgreSQL is falling apart” post. The project reverts things late every year; the PostgreSQL 11 cycle had a scariest-patch tournament of its own, and WAIT FOR took a decade and three reverts to land. But 19 is different in degree.

Leave a Comment

NOLOCK Hurts, Even with Indexes

Brent Ozar proves a point:

NOLOCK is bad and you probably shouldn’t use it, but every time I mention that publicly, the pushback just keeps coming. I don’t know why people so firmly believe that their situation couldn’t possibly be affected by bad/random data from NOLOCK.

Today’s misconception comes from a LinkedIn commenter telling me it’s safe to use if you’re doing index seeks. Hoo boy. 

Click through for the proof.

Leave a Comment

CU Consumption after the Query Finishes

Nikola Ilic answers a question:

After my article on Fabric Warehouse CU metering, which caused a lot of people reaching out and mentioning that it helped them understand the topic better, I decided to cover SQL database in Fabric from a similar angle too.

Imagine opening an internal application, updating a few records, and closing it two minutes later. You check consumption afterward and see that compute continued accruing.

Before blaming the application, it helps to understand what keeps the database online, and what Fabric actually measures.

Read on for that answer.

Leave a Comment

Certificate-Based Authentication and Availability Groups

Jordan Boich shares a story:

A few months after a clean migration, replication between the nodes in the global primary AG in a Distributed Availability Group (DAG) just stopped. There were no new deployments, config changes, or specific warning signs prior to this. Windows patching had occurred, the servers rebooted like they usually would, and the AG never came back together.

I know for myself, one of the most frustrating phrases that gives me the sense of impending doom is “nothing changed, why is this breaking?!”. That’s exactly what was going on here.

Read on to see how an innocent-looking configuration setting can cause issues down the road.

Leave a Comment

A Review of SQL Database in Microsoft Fabric

Paul Turley shares some thoughts:

When I first learned that SQL Server databases were coming to Fabric, I wasn’t entirely sure how and why we would use it. Now that I’ve had a chance to use SQL Database in Fabric, I wanted to share some of my experience and thoughts about where and how it makes sense to use it. I thought: Fabric is an analytics platform, and we primarily store data in a Lakehouse or warehouse to prep it up for reporting and analysis with Power BI. Why would I want to store data in a SQL Server database in the Fabric SaaS environment? I’ve since implemented “SQL Database for Fabric” (aka “Fabric SQL Database”) in several projects and I’m just blown away by how fast and simple it is to use. In this post, I will dig into the cost and performance and use cases where this option makes the most sense compared to other hosted implementations of the SQL Server database engine.

Click though to learn more.

Leave a Comment

Tuning DiskANN

Mala Mahadevan wraps up a three-parter on how DiskANN works:

In Part 1, we saw how ‘Vamana’ represents vectors as nodes, connects them with edges, and uses greedy graph traversal to avoid comparing a query against every vector in the dataset. In Part 2, we investigated how PQ gave us compact representations for inexpensive distance calculations, caching kept useful graph nodes close, how SSDs provided capacity, and beam search allowed multiple promising nodes to be expanded together.

In this last part, we will be exploring how we use the parameters to tune DiskANN.

Click through to learn more about these parameters and what they do.

Leave a Comment