Query Tuning – Curated SQL

Performance Comparison: Tally Table vs GENERATE_SERIES()

Published 2025-03-06 by Kevin Feasel

I had someone reach out about generate_series() recently, saying they hadn’t realized this was a new feature in SQL Server 2022. They were wondering if it was better than using a tally table.

I didn’t want to do an exhaustive test, but I thought I’d take a minute and try a couple simple things just to see.

Steve used the CTE-based tally table builder, building based on cross joining spt_values. This is one of the classic approaches. The performance differences aren’t enough on their own to justify large-scale changes if you’re using a classical tally table, though it is good to see that GENERATE_SERIES() does perform well. And if you’re not familiar with the power of a tally table, here is one great explanation of the concept.

Leave a Comment

Visualizing PostgreSQL Query plans

Published 2025-03-06 by Kevin Feasel

MIchael Christofides views a plan:

When you’ve got a slow Postgres query, EXPLAIN and its parameters are incredibly useful for working out why.

However, the information returned can be difficult and time-consuming to interpret, especially for more complex queries. Over the years, people have built quite a few tools for visualizing Postgres query plans. As one of those people, I’m ~~a little~~ incredibly biased, but as a fan of many of the others, I hope to do them justice.

Read on for the options. I think the SQL Server world is a bit spoiled with Solarwinds Plan Explorer (even if the product hasn’t really changed since Solarwinds bought Sentry One), but some of these options look very solid.

Leave a Comment

Making a Query SARGable

Published 2025-03-05 by Kevin Feasel

Haripriya Naidu explains SARGability:

Having the right index is helpful, but are you using the predicate (WHERE clause) correctly to make efficient use of that index?

This is where the term SARGable comes into play. SARGable stands for Search ARGumentable. If SQL Server is able to limit the search space while evaluating the predicates and can seek right at the page(s) to get the values, then it is SARGable.

Read on for an explanation of why this is important, as well as several examples of what is SARGable versus what isn’t. The most important thing about SARGability is that you pronounce it like “Sarge” and not “sarg.”

Leave a Comment

Reading Buffers Numbers in PostgreSQL Explain Plans

Published 2025-02-18 by Kevin Feasel

Brent Ozar busts out the calculator:

You’re tuning a Postgres query and you’ve been told to run EXPLAIN with the BUFFERS option, like this:

EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS)

But the output like this is confusing, because the numbers don’t add up vertically or horizontally. It’s just a whole mess of numbers that seem unrelated:

Read on to learn more about which numbers to pay attention to and what they all mean.

Leave a Comment

Inlining Views in PostgreSQL

Published 2025-02-10 by Kevin Feasel

Radim Marek shows off how the PostgreSQL database engine can inline a view:

Database VIEWs are powerful tools that often don’t get the attention they deserve when building database-driven applications. They make our database work easier in several ways:

They let us reuse common query patterns instead of writing them over and over

They give us a place to define business rules once and use them everywhere

They help us write cleaner, more organized queries

Let’s see how this works with a practical example.

I’m not sure how well PostgreSQL manages nested views, as the biggest problem in SQL Server with inlining views comes when you have overly complicated views made up of views joined to views made up of views joined to–well, you get the idea. That said, Radim does point out a variety of scenarios in which inlining doesn’t happen in PostgreSQL.

Comments closed

SQL Server 2019 and Row Mode Memory Grant Feedback

Published 2025-01-23 by Kevin Feasel

Yvonne Vanslageren explains a solid feature in SQL Server 2019:

When SQL Server runs a query, it needs memory for operations like sorting and joining data. It also relies on memory during query compilation to hold intermediate plans while the Query Optimizer finds the best execution strategy. In parallel processing scenarios, the memory requirement grows even further.

SQL Server manages this by pre-allocating memory for each query through the SQL Server Operating System (SQLOS). This process ensures that no single query can monopolize the server’s memory.

Read on to learn more about memory grants, problems you can run into with memory grants, and one way SQL Server 2019 has improved to reduce the risk of bad memory grant estimates.

Comments closed

Working with DBCC OPTIMIZER_WHATIF

Published 2025-01-15 by Kevin Feasel

Yvonne Vanslageren shows off a very uncommon DBCC command:

DBCC OPTIMIZER_WHATIF is a powerful diagnostic command in SQL Server that allows database administrators and developers to simulate various hardware configurations. By doing so, it shows how the query optimizer would behave under different CPU and memory allocations—without requiring you to physically change server hardware. This makes it an invaluable tool for performance tuning, troubleshooting, and strategic planning in SQL Server environments.

This obviously won’t actually make things faster, but will help you answer questions like “would more CPU cores improve this query or do I need to dump more RAM into the server?”

Comments closed

PostgreSQL and Indexing on EXTRACT()

Published 2024-12-30 by Kevin Feasel

Henrietta Dombrovskaya troubleshoots a performance problem:

It’s Christmas time and relatively quiet in my day job, so let’s make it story time again! One more tale from the trenches: how wrong you can go with one table and one index?

Several weeks ago, a user asked me why one of the queries had an “inconsistent performance.” According to the user, “Sometimes it takes three minutes, sometimes thirty, or just never finishes.” After taking a look at the query, I could tell that the actual problem was not the 30+ minutes, but 3 minutes – when you have a several hundred million row table and your select yields just over a thousand rows, it’s a classical “short query,” so you should be able to get results in milliseconds.

Read on for the problem, as well as how Henrietta was able to coerce the PostgreSQL optimizer into choosing the correct path.

Comments closed

Fractional Path Performance Issues in Postgres Partitioned Tables

Published 2024-12-16 by Kevin Feasel

Andrei Lepikhov digs into an interesting finding:

While the user notices the positive aspects of technology, a developer, usually encountering limitations, shortcomings or bugs, watches the product from a completely different perspective. The same stuff happened at this time: after the publication of the comparative testing results, where Join-Order-Benchmark queries were passed on a database with and without partitions, I couldn’t push away the feeling that I had missed something. In my mind, Postgres should build a worse plan with partitions than without them. And this should not be just a bug but a technological limitation. After a second thought, I found a weak spot – queries with limits.

Read on to see what Andrei came up with.

Comments closed

Number of Rows Read in SQL Server Execution Plans

Published 2024-12-11 by Kevin Feasel

Rob Farley cashed in all of his chips and got something nice out of it:

I had written to Santa (okay, the product group at Microsoft) to ask for this. It wasn’t quite “If I’m on the nice list, what I’d like is a unicorn train set”, but more like “If it’s not too much trouble, this thing here would be amazing…”

The thing was the ability to see the “number of rows read” by an Index Seek operation in a SQL plan containing the “Actuals” (post-execution).

Read on for information about why this is so useful.

Comments closed

Category: Query Tuning