Press "Enter" to skip to content

Author: Kevin Feasel

Table Statistics and Planning Slowdowns

Published 2026-01-29 by Kevin Feasel

Andrei Lepikhov digs into a performance issue:

A query executes in just 2 milliseconds, yet its planning phase takes 500 ms. The database is reasonably sized, the query involves 9 tables, and the default_statistics_target is set to only 500. Where does this discrepancy come from?

This question was recently raised on the pgsql-performance mailing list, and the investigation revealed a somewhat surprising culprit: the column statistics stored in PostgreSQL’s pg_statistic table.

Read on for Andrei’s analysis and some interesting thoughts on possible avenues for improvement.

Comments closed

Materialized Lake Views in Microsoft Fabric

Published 2026-01-28 by Kevin Feasel

Jon Lunn digs into a somewhat-new feature:

So first off, what are they? They are basically a table object that is based on a query. (Yes I know they are called ‘Views’… more on that later) So like a view, it is defined by a SQL query, but it doesn’t just sit over tables and runs that SQL when you query that view. What it does do is take the ‘View’ SQL query that defines the Materialised Lake Views, runs it and stores the query result data into a delta table. So when you query that view, you get the data from that object, and not the underlying tables. Neat! Save a bit on computing query time!

Read on to learn more about what they are, how they work, and when they can be useful.

Comments closed

Setting up Azure SQL Mirroring to Microsoft Fabric

Published 2026-01-28 by Kevin Feasel

Olivier Van Steenlandt troubleshoots an issue:

When setting up database mirroring from Azure SQL to Microsoft Fabric for one of my demo databases, I ran into an issue while trying to connect to my Azure SQL database.

As you can see in the screenshot above, it seems that a setting on my logical SQL Server in Azure is misconfigured. Let’s resolve that in a couple of steps.

Click through for the screenshot, the specific error, and how Olivier was able to get things working.

Comments closed

The Complexity of Cloud Security

Published 2026-01-28 by Kevin Feasel

Rebecca Lewis shares a tale of woe:

Cloud-based SQL Server security isn’t simpler. It’s different — and the learning curve is brutal if you grew up on-prem.

If you’ve spent years working Windows authentication, SQL logins, role memberships, and the occasional certificate, you may assume cloud security is more of that, just with a portal. Not. The SQL Server/Cloud permission models are layered differently, the terminology shifts depending on the platform, and the people who ‘own’ security are spread across teams that don’t always speak the same language.

Read on for an example of the kinds of challenges you can run into. Adding to that complexities around managed identities and authorization mechanisms and things can get very convoluted, even when the intent is to simplify matters.

1 Comment

T-SQL Tuesday 194 Round-Up

Published 2026-01-28 by Kevin Feasel

Louis Davidson has made a big mistake:

As I sit here, preparing to write my roundup post, I have not read anyone else’s post yet. I thought it would be good to introduce the idea first, recap to the other posts, then mine. I won’t share any detail of the mistake I shared, but I do want to mention something I included in my post. Types of mistakes. Mistakes of choice, and mistakes of accidents.

Read on for a nice round-up of a popular topic.

Comments closed

Workspace-Level Surge Protection Controls in Microsoft Fabric

Published 2026-01-28 by Kevin Feasel

Pankaj Arora announces a new preview feature:

Until now, surge protection applied only at the capacity level—meaning all workspaces shared the same rules.

What’s new: workspace-level surge protection

We’re taking surge protection to the next level with workspace-level controls. This update gives you more granular management of compute usage across your organization.

Read on to see what this means for organizations using Microsoft Fabric.

Comments closed

Showing Transaction Details on Power BI Matrices

Published 2026-01-27 by Kevin Feasel

Marco Russo and Alberto Ferrari want more detail:

A common challenge in Power BI reporting is how to display several pieces of information about a single item (such as sales transactions, product details, or customer details) without dedicating a separate column to each attribute. Using individual columns for each detail can consume space, especially for fields that are often empty. This article explores techniques to consolidate multiple fields from a business entity or transaction into a single column in a matrix visual, thus presenting transaction details in a space-efficient way.

They walk through several iterations of the process. The real challenge with displaying those details is that your end users need to understand what’s in the details, as there’s no good way to describe what the information means. But when your users do understand what can be in there, I could see this being quite helpful.

Comments closed

Buffers in PostgreSQL

Published 2026-01-27 by Kevin Feasel

Radim Marek goes deep into buffers:

The work around RegreSQL led me to focus a lot on buffers. If you are a casual PostgreSQL user, you have probably heard about adjusting shared_buffers and followed the good old advice to set it to 1/4 of available RAM. But after we went a little bit too enthusiastic about them on a recent Postgres FM episode I’ve been asked what that’s all about.

Buffers are one of those topics that easily gets forgotten. And while they are a foundation block of PostgreSQL’s performance architecture, most of us treat them as a black box. This article is going to attempt to change that.

Read on to learn more about how PostgreSQL users buffers.

Comments closed

Tracking Unused Indexes in PostgreSQL

Published 2026-01-27 by Kevin Feasel

Semab Tariq wants to see which indexes are in use:

Indexes exist to speed up data access. They allow PostgreSQL to avoid full table scans, significantly reducing query execution time for read-heavy workloads.

From real production experience, we have observed that well-designed, targeted indexes can improve query performance by 5× or more, especially on large transactional tables.

However, indexes are not free.

The reasons for why are very similar to what we have in SQL Server. The way to track utilization is a bit different, however.

Comments closed