Mastering Postgres
Introduction
Introduction to the course
Overview of course structure
Postgres vs. everyone
The psql CLI
Data Types
Introduction to schema
Integers
Numeric
Floating point
Storing money
NaNs and infinity
Casting types
Characters types
Check constraints
Domain types
Charsets and collations
Binary data
UUIDs
Boolean
Enums
Timestamps
Timezones
Dates and times
Advanced Data Types
Intervals
Serial type
Sequences
Identity
Network and mac addresses
JSON
Arrays
Generated columns
Text search types
Bit string
Ranges
Composite types
Nulls
Unique constraints
Exclusion constraints
Foreign key constraints
Indexing
Introduction to indexes
Heaps and CTIDs
B-Tree overview
Primary keys vs. secondary indexes
Primary key types
Where to add indexes
Index selectivity
Composite indexes
Composite range
Combining multiple indexes
Covering indexes
Partial indexes
Index ordering
Ordering nulls in indexes
Advanced Indexing
Functional indexes
Duplicate indexes
Hash indexes
Naming indexes
Understanding Query Plans
Introduction to explain
Explain structure
Scan nodes
Costs and rows
Explain analyze
Generating Results
Introduction to queries
Cross joins
Inner joins
Outer joins
Subqueries
Lateral joins
ROWS FROM
Filling gaps in sequences
Subquery elimination
Combining queries
Set generating functions
Indexing joins
Advanced SQL
Introduction to advanced SQL
Grouping
Grouping sets, rollups, cubes
Window functions
CTEs
CTEs with window functions
Recursive CTE
Hierarchical recursive CTE
Handling nulls
Row value syntax
Views
Materialized views
Removing duplicate rows
Upsert
Returning keyword
COALESCE + generated column
Full Text Search
Introduction to full text search
Searching with LIKE
Vectors, queries, and ranks
Websearch
Ranking
Indexing full text search
Highlighting
Advanced JSON
Intro to JSON
JSON vs JSONB
Validating JSON
Creating JSON objects + arrays
JSON extraction
JSON containment
JSON existence
JSON recordset
Updating JSON
Indexing JSON parts
GIN index
Vectors (pgvector)
Intro to pgvector
Vector embedding columns
Find related articles
Upsert vector embedding
Semantic search
Other operators
Vector indexes
Outro
Thank you
Bonus interviews
Heroku's glory days & Postgres vs the world (with Craig Kerstiens)
Creating a Postgres platform with Monica & Tudor from Xata.io
Bootstrapping an email service provider (with Jesse Hanley)
Locked video

Please purchase the course to watch this video.

Video thumbnail
Advanced Indexing
Naming indexes

Full Course

$
349
$399
USD, one-time fee
The course "Mastering Postgres" helped me practice query commands and understand why they're important. Inspiring me to explore the 'why' and 'how' behind each one. Truly a great course!
Nakolus
Nakolus

PostgreSQL database platform

Shorten dev cycles with branching and zero-downtime schema migrations.

Test Data

I've made my test data available for you to use and follow along.

Download
or
Use on Xata

Summary

Naming indexes clearly and consistently helps prevent conflicts and keeps your database schema organized. A common pattern like `{tablename}_{column}` ensures uniqueness and makes it easier to understand what each index is for. While concise names work well for learning and demos, using descriptive names in production environments is a best practice for long-term maintainability.

Video Transcript

One last thing I want to cover here before we really get going is an index naming strategy or pattern. Index names are not global to a database, but they are global to a schema.

If you have an index on email and you name it email and you have another index on email and a different table, you're gonna be host. I want to show you a little bit of an index naming strategy and then at the end we'll talk about why I am not gonna do that in these videos. If I ran create index and I just named it foo on, we'll just call it users(id);. I think we have, what do we have? We have addresses still lying around and I'm gonna try to name that one foo as well.

You cannot create two of the exact same index name in the same schema. We're in the public schema here and you just can't do that. A very common pattern here, let me get, let me get down here and let's just do this. A very common pattern here is to say {tablename}_{column} or {column(s)}, you know, depending, and then some sort of type. You could have just an {index}, you could have a {check}, you could have a {unique}, you could do something like that. In reality, this index would be better names users_id.

Right here I'm just creating a regular index. You'd probably do it on something like email where you have a regular index there and you say, users_email_idx. You can come up with whatever pattern you want. I do think prefixing with the table name is probably a good idea 'cause that does add a little layer of separation between all of your separate indexes. It's up to you. It's up to your team. It might even be up to your framework. I know that a lot of these frameworks with ORMs that generate migrations, create their own index names. That's great. You're almost guaranteed that they're gonna be unique. That's a good thing. I'm not gonna spend all the time typing these out in the next videos.

You should, in production, have nice clean index names for the sake of brevity and to keep things moving quickly. I'm just gonna type out some short index names, but don't do that in production.