Press "Enter" to skip to content

Category: Indexing

Accounting for Index Usage over Availability Groups

Published 2025-10-06 by Kevin Feasel

Aaron Bertrand wants a cross-replica accounting system:

As a part of optimizing performance, I evaluate index usage across many instances and databases. I often find that some indexes aren’t used much or, at least on first glance, appear to go unused. Since we use availability groups (AG), different workloads run against replicas in different roles. All writes happen on the primary, obviously. However, some queries only happen on read-only secondaries (either because read-only routing is in use, or because some processes are manually directed at specific secondaries, or both). Unfortunately, index usage is not rolled up anywhere across all replicas. This means that looking at the primary alone gives an incomplete picture. How do I make sure I account for index activity everywhere, not just on the primary?

This is part one of a series but already has enough to get us started.

Leave a Comment

Bitmap Indexes and Deadlocks in Oracle

Published 2025-09-24 by Kevin Feasel

David Fitzjarrell looks at bitmap indexes:

Bitmap indexes can be very useful, especially when NULL columns are present, as a bitmap index will include such values when btree indexes may not, such as entirely null index keys. Unfortunately bitmap indexes do not behave well with concurrent transactions, where deadlocks may arise because of the bitmap index.

Oracle will trap, report and “resolve” deadlocks by assessing the situation, determining which session created the deadlock and killing the ‘offending’ session, with no manual intervention required. The trace file generated reports this as an issue with application coding and/or logic and in many cases this is the likely cause. Enter the bitmap index and a concurrent transaction and, mysteriously, a deadlock may appear, confounding the developer and the DBA.

Read on to learn more about how bitmap indexes can provide a (potentially) strange source of deadlocks.

Leave a Comment

PostgreSQL and (Lack of) Clustered Indexes

Published 2025-09-15 by Kevin Feasel

Brent Ozar shares a surprise if you’re coming from the SQL Server world:

Postgres starts with a very different assumption: it uses multi-version concurrency control (MVCC, or what SQL Server folks call RCSI) by default, right from the get-go. When we update rows, Postgres automatically makes new versions of the rows, storing them inside the same table. There’s no need to enable it – it’s on for all databases, by default.

So because Postgres is constantly creating new versions of rows, it doesn’t really make sense to store the table itself in some kind of order.

Every table is a heap.

This fundamental storage difference has some ramifications for query tuning and indexing strategy that makes the two platforms quite different.

Comments closed

Rolling Filtered Indexes in SQL Server

Published 2025-08-19 by Kevin Feasel

Aaron Bertrand only needs recent data:

I recently resolved an issue where a query pulling data from the last 30 days would time out due to the table’s size and the lack of a supporting index. Creating a supporting index is possible, but not ideal; it will be very large and may not be useful for most queries and use cases. I wonder how I could implement a filtered index that follows time and is always limited to the last n days.

Read on to see how Aaron did this. It’s a clever solution and Aaron does make clear the tricky part of filtered indexes: explicit conditions.

Comments closed

Thoughts on Index Rebuilds in PostgreSQL

Published 2025-08-12 by Kevin Feasel

Laurenz Albe shares some advice:

People often ask “How can I automatically rebuild by indexes regularly?” or “When should I rebuild my indexes in PostgreSQL?”. That always gives me the feeling that they want to solve a problem that isn’t there. But the REINDEX statement is certainly there for a reason, and sometimes it is perfectly reasonable to rebuild an index. In this article, I’ll explain when it makes sense to rebuild an index and how you can get the relevant data to make that decision.

Read on to learn more.

Comments closed

Digging Further into RTABench Q0 Optimization on PostgreSQL

Published 2025-08-08 by Kevin Feasel

Andrei Lepikhov responds to feedback:

In the previous post, I explored some nuances of Postgres related to indexes and parallel workers. This text sparked a lively discussion on LinkedIn, during which one commentator (thanks to Ants Aasma) proposed an index that was significantly more efficient than those discussed in the article. However, an automated comparison of EXPLAINs did not clarify the reasons for its superiority, necessitating further investigation.

Click through for the index and what Andrei learned along the way.

Comments closed

Making Leading Wildcard Searches Faster

Published 2025-08-07 by Kevin Feasel

Brent Ozar flips everything around:

99.9% of you are never gonna need this.

But let’s say you need to run queries with leading (not trailing) wildcards, like this search for all the different national versions of the Encabulator, each of which has different prefixes depending on which government it’s being sold to:

This is indeed a pretty uncommon scenario. I’m pretty sure I’ve only ever needed to do this once. Well, twice, but in one case I couldn’t actually use the REVERSE() function because the column was itself an awful non-deterministic function and this solution wouldn’t work.

Comments closed

PostgreSQL and Covering Indexes

Published 2025-06-30 by Kevin Feasel

Kendra Little does a bit of index management:

Dear Postgres, Why won’t you use my covering index?

Lately I’ve been learning to tune queries running against PostgreSQL, and it’s pretty delightful. One fun question that I worked through struck me something that most Postgres users probably encounter one way or another: sometimes you may create the perfect index that covers a given query, but the query planner will choose to ignore it and scan the base table.

Why in the world would it do that?

Read on to learn why.

Comments closed

Index Maintenance for Large Databases

Published 2025-06-27 by Kevin Feasel

Jon Russell shares some thoughts:

Most database administrators are comfortable with the daily tasks of backup, CHECKDB, index maintenance, and statistics updates. The available guidance for those topics is extensive. Much less has been written about caring for estates that contain hundreds of databases—or a single database large enough to strain conventional maintenance windows. This post will focus on options that help when individual tables or complete databases grow beyond the point where “standard” maintenance jobs finish in a reasonable time.

Click through for Jon’s advice. My big thing is to stop worrying and learn to love the bomb fragmentation. Index fragmentation was very important back in the days of spinning disk, where accessing pages took much longer if you needed to move the disk head. With NVMe storage, all-flash arrays, and even more prosaic solid state drives, random access is typically at least as fast as sequential access, so there’s no real benefit to having pages of data be contiguous.

Comments closed