Scaling Postgres Episode 245 ENUM vs Check Constraint, Faceting With Roaring Bitmaps, Better Scaling

To get the show notes as well as get notified of new episodes, visit:

In this episode of Scaling Postgres, we discuss ENUMs vs. check constraints, querying table facets with roaring bitmaps, a better way to handle scaling and whether you should store your business logic in Postgres.

Want to learn more about Postgres performance?

Timestamps:
00:00 - Intro
00:29 - Enums vs Check Constraints in Postgres
02:02 - Faceting large result sets in PostgreSQL
04:15 - pgfaceting Extension
04:54 - Roaring Bitmaps and pgfaceting: Fast counting across large datasets in Postgres
05:15 - ISO Better Scaling, Instacart Drops Postgres for Amazon DynamoDB
07:21 - Rubber Duck Dev Show Episode 68 | Should You Store Business Logic In Your Database?
08:20 - Debugging Postgres WAL events with pg_walinspect
09:16 - The bountiful world of Postgres indexing options
10:12 - PGSQL Phriday #003: What is the PostgreSQL Community to me
10:29 - Postgres support for JSON is 10 years old!
10:51 - Timestamps
11:03 - Aleš Zelený
11:15 - Outro

#postgres #postgresql

[friesencr]

we use enums all the time. we had used integers for types for speed but they are not human readable. enum gets stored as a byte which is small. they also are easily handled in code as strings. if you have a terrible legacy system that uses polymorphic tables ie rails activerecord, ar uses strings and postgres will transform on the way in and out. because they are small index size and join speed are much faster. downside is migrations require disabling transactions.