Press "Enter" to skip to content

Day: February 4, 2025

Alternatives to Error Bars

Alex Velez admits to error:

During a client workshop, someone asked me if I was a fan of error bars and whether they should use them in their presentations. As I readied my standard “it depends” response, I realized that for once, it didn’t depend. I couldn’t think of a single time when error bars would be the ideal solution for communicating data. (For clarity, if they had asked whether they should articulate the margin of error around their data, my answer would have certainly been it depends. I just wouldn’t use error bars to do so.)

Before I discuss why I’m not a fan of error bars and an alternative solution, let’s explore what they are. 

Click through for Alex’s thoughts, including a pair of interesting alternative displays.

Leave a Comment

Indexing a Materialized View in PostgreSQL

Elizabeth Christensen adds an index:

Materialized views are widely used in Postgres today. Many of us are working with using connected systems through foreign data wrappers, separate analytics systems like data warehouses, and merging data from different locations with Postgres queries. Materialized views let you precompile a query or partial table, for both local and remote data. Materialized views are static and have to be refreshed.

One of the things that can be really important for using materialized views efficiently is indexing.

Adding indexes to Postgres in general is critical for operation and query performance. Adding indexes for materialized views is also generally recommended for a few different reasons.

Click through for those reasons. This article illustrates some of the differences between indexed views in SQL Server and materialized views in PostgreSQL.

Leave a Comment

What to Do when SQL Server Ignores Your Non-Clustered Index

Mehdi Ghapanvari wants us to think of the poor, downtrodden non-clustered indexes:

Do you wonder why SQL Server ignores an index? Do you think about how you can deal with this problem? When you include too many columns in a query you decrease index selectivity. So, if you write a query like “Select * From …” the chance of choosing your nonclustered index will decrease.

The article is generally sound, though not all-inclusive. If you really want to use an index, you can use index hints. I personally have no qualms about using them, though hints are telling the optimizer that you know better than it, so be really sure you do actually know better than it before shipping that off.

Leave a Comment

Choosing the Right Power BI Canvas

Elena Drakulevska shares some advice:

The same goes for your Power BI report—get the size wrong, and your users will struggle with cluttered visuals, excessive scrolling, or awkward gaps. Or worse, you’ll create a report that looks amazing on your screen but completely breaks when someone else opens it.

Trust me, I’ve seen it—an ultrawide masterpiece designed for the boss’s fancy monitor… except no one else at the company had that monitor.

Yeah, this brings back memories, though in my case, it was that the developers (including me) had wide-screen monitors in 1080p and the people using our product had standard resolutions like 1280×1024 or even 1024×768.

Leave a Comment

Billing for SQL Database in Microsoft Fabric

Amar Digamber Patil makes an announcement:

Since SQL database is a native item in Fabric, it utilizes Fabric capacity units like other Fabric workloads. Compute charges apply only when the database is actively used, so you only consume what you need. Storage is billed separately on a monthly basis, as are automatic backups, which are retained for seven days.

Billing for compute usage and data storage for SQL databases in Fabric will commence after February 1st.

Click through for more information, including links to more information regarding billing and monitoring.

Leave a Comment

Reducing Query Timeout on DAX and MDX Queries

Chris Webb shuts it down:

The recent announcement of Surge Protection gives Fabric/Power BI capacity admins a way to restrict the impact of background operations on a capacity, preventing them from causing throttling. However, at the time of writing, Surge Protection does not prevent users that are running expensive DAX or MDX queries – which are interactive operations – from causing problems on your capacity. Indeed, right now, there is no direct way to stop runaway queries from consuming a lot of CUs, although there is something you can do which will help a lot: reducing the query timeout.

Read on for information about why Surge Protection doesn’t currently work with DAX and MDX queries, and how you can change the query timeout. This is kind of interesting considering that, outside of the Microsoft Fabric world, we typically move the query timeout higher rather than lower, to deal with long-running queries.

Leave a Comment