Category: Indexing

Henrietta Dombrovskaya continues a series on Postgres:

What is an index? One might assume that any person who works with databases knows what an index is. However, a surprising number of people, including database developers and report writers and, in some cases, even DBAs, use indexes, even create indexes, with only a vague understanding of what indexes are and how they are structured. Having this in mind, let’s start with defining what is an index.

Since there are many different index types in PostgreSQL (and new index types are constantly created) we won’t focus on structural properties to produce an index definition. Instead, we define an index based on its usage.

Indexing is one area in which SQL Server and Postgres differ, as SQL Server relies on clustered indexes for storage and “default” operations, whereas Postgres has a different model.

Adron Hall gives us a tour of indexes in several relational database management systems:

1. Structure of the Craft: Dive deep, and you’d find tree-like structures, be it the B-tree or its illustrious cousins – the B+ tree and B* tree. These aren’t ordinary trees; they’re a labyrinth that efficiently guides the system to the row it seeks in a jiffy.
2. Guiding Stars – Pointers: Each entry in this labyrinth isn’t just a dead end. It carries a key value and – wait for it – a pointer. Think of it as a magical compass pointing directly to the treasure, or in this case, the row in the table.
3. Supercharged Searches: Now, imagine sifting through a library without a catalog – agonizingly slow, right? That’s how a database without an index feels. But bring in an index, and suddenly even the vastest of tables become a playground of swift searches.

Read on for an overview of what purposes indexes fulfill in these data platforms. I use “purposes they fulfill” rather than “types of indexes” because there are a couple entries on the list which are not, strictly speaking, actual types of indexes.

Jose Manuel Jurado Diaz shares a note:

During a remote session with a customer, a comparison between the source and target databases revealed a discrepancy in the indexes. Specifically, while the source database contained three types of indexes (PK_xxx, IX_xxx, and NCI_xxx), only the manually created PK_xxx and IX_xxx indexes were visible in the target database after restoration. The absence of NCI_xxx indexes prompted an investigation into the BACPAC export process.

This meant that the BACPAC file didn’t have the set of recommended automatic indexes. Click through for the explanation, though I’m not sure there’s a good way to fix it, short of manually scripting out those automated indexes yourself.

Andrea Allred doesn’t want that index to resume:

It had been building for about 10 minutes, when I realized I had the fields in the wrong order. No big deal, I just canceled it, corrected it and tried to start it again. “Tried” was the keyword here. I got an error because I had set RESUMABLE = ON but hadn’t properly cleared it out of the system. I started to furiously dig through articles about how to clear out an index that was resumable but had been canceled.

Read on to see what Andrea found.