If you want faster reports, Karen Jex gives a good high-level overview of Postgres settings to review. This isn’t about giving you exact setting values, but more about a list of places to look.

Postgres tries to parallelize queries to make them go faster, but when a lot of parallel queries are running at once, queries might get downgraded to single-threaded execution. Brian Pace explains & demos how it happens and talks about ways to fix it.

If your query is using indexes, that doesn’t mean it’s as fast as it can go, as Michael Christophides explains with examples.

If you need auditing logs for logins, or if you want to lock people out of the database based on times, Hans-Jürgen Schönig explains how to use login triggers. Just be careful: if your app connects hundreds or thousands of times per second (like it doesn’t use connection pooling properly), then you can easily overwhelm a logging table.

If you have a busy OLTP app with hundreds of commits per second, Laurenz Albe demonstrates how the commit_delay setting can group them together to reduce writes/IOPs for faster storage response times. This only makes sense on busy write-heavy apps, though, otherwise you’re just adding a delay to your write transactions.