Créer et utiliser des index

In the last lesson, we learned about B-Tree indexes, the most common type in PostgreSQL. Now, let's get practical! This lesson will guide you through creating, using, and managing indexes to boost your query performance.

You'll learn the syntax, see practical examples, and understand when and how to apply indexes effectively.

The basic syntax for creating an index is straightforward. You specify the table, the column(s) to index, and optionally the index type (though B-Tree is default and most common).

• CREATE INDEX: The command to create a new index.
• index_name: A unique name you choose for your index.
• table_name: The table on which the index is built.
• column_name(s): The column(s) to include in the index.

Let's create a simple products table, insert some data, and then add a single-column index. This setup will be used in subsequent examples.

After creating an index, it's a good practice to confirm it exists. PostgreSQL provides a few ways to inspect your table's structure and its associated indexes.

• In the psql command-line client, type \d products to see details for the products table, including its indexes.
• Alternatively, you can query system catalog tables like pg_indexes: SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'products';

Indexes are most effective when PostgreSQL needs to quickly locate specific rows without scanning the entire table. Think of them like the index in a textbook, pointing directly to relevant pages.

• WHERE clauses: Filtering data by indexed columns (e.g., WHERE category = 'Electronics').
• ORDER BY clauses: Sorting data by indexed columns.
• JOIN conditions: Connecting tables on indexed columns.

Without an index, PostgreSQL might perform a slow "sequential scan" on large tables.

Let's use EXPLAIN to see how our idx_products_category index can help a query that filters by the category column. EXPLAIN shows the query plan, revealing if an index is used.

Sometimes, your queries filter or sort by *multiple* columns together. In such cases, a composite index (or multi-column index) can be highly beneficial.

It includes more than one column, and the order of columns matters! Place the most frequently used or most selective columns (those with more unique values) first.

Let's create a composite index on both category and price. This would be useful for queries that filter by category and then further filter or sort by price within that category.

Indexes aren't always a magic bullet. They come with trade-offs:

• Storage space: Indexes consume disk space, potentially a lot for large tables.
• Write overhead: Every INSERT, UPDATE, or DELETE on an indexed column requires updating the index, which can slow down write operations.
• Over-indexing: Too many indexes can confuse the query planner or increase write overhead, hurting overall performance.

Avoid indexing columns with very few unique values (e.g., a boolean is_active column).

If an index is no longer needed, or if you've created a better one, you can easily remove it using the DROP INDEX command. This frees up storage space and reduces write overhead on your database.

You've learned how to create and manage indexes. Let's test your understanding!

Fantastic work! In this lesson, you learned the practical steps for creating and managing indexes in PostgreSQL:

• We used the CREATE INDEX command to add indexes to tables.
• We explored both single-column and composite (multi-column) indexes.
• You learned when indexes are beneficial (WHERE, ORDER BY, JOIN) and their trade-offs (write overhead, storage).
• Finally, you also learned how to verify and remove indexes using DROP INDEX.

Next, we'll dive deeper into best practices for deciding *which* columns to index and how to avoid common pitfalls!