Press "Enter" to skip to content

Day: July 6, 2026

When Additional Data Doesn’t Shrink Confidence Intervals

John Cook follows Betteridge’s Law of Headlines:

In general, new information reduces your uncertainty regarding whatever you’re estimating. The posterior distribution becomes more concentrated as more data are collected.

That’s what happens “in general” but does it necessarily happen every time you get new data? Conceivably if you get surprising data, data that is very unlikely given your current prior, posterior uncertainty might increase.

Click through for an example, as well as a pair of good comments on the post.

Leave a Comment

Power BI: Database Was Evicted to Balance the CPU Load

Chris Webb diagnoses a case of passive voice:

A few months ago I wrote about a rare error – the “Maximum allowable memory allocation” error – that may occur when the physical machine, or node, that a semantic model is running on in the Power BI Service comes under memory pressure. Recently, someone I was working with who was doing some load testing showed me a related error:

The operation was canceled and the database was evicted to balance the CPU load on the node. Please try again later.

Read on to see what causes this.

Leave a Comment

Ways Data Apps Improve Microsoft Fabric Semantic Models

Ruben Van de Voorde digs into data apps:

Fabric data apps are the most interesting thing to happen to data visualization in Power BI and Microsoft Fabric, ever. They provide limitless potential for how to visualize and interact with your data. However, they also indirectly provide a major benefit to your semantic models by allowing them to be simpler to build, use, and maintain.

In this article, we argue that data apps provide a reporting layer that is separate from the semantic layer, something that wasn’t true in Power BI due to tight coupling between reports and semantic models.

Click through to see where they fit vis-a-vis Power BI reports and semantic models.

Leave a Comment

Ghost Records in SQL Server

Martyn Jones sees dead records:

When a delete operation is executed, or when an update causes a page split, a marker is set in the page header, and each row is marked to show that the record is to be deleted; this is the process of creating ghost records. The concept is to improve performance as the data is not immediately removed, and, with row-level locking, it helps minimise blocking and supports efficient concurrency under typical isolation levels such as Read Committed and above. If a transaction is later rolled back, the cost of effectively restoring the row is considerably reduced as the data doesn’t need to be reinserted, only the marker removed. Later demos will show this in action.

This is the first part of a longer series on ghost records and ghost cleanup.

Leave a Comment