Links - 13^th November 2022

So we’ve told you a bunch of information about clusters, databases, and schemas, but you’re wondering how it fits in practically.

• Clusters are the full instance that is running Postgres itself. You’re not getting away from this one, but know that base backups and WAL from a cluster is all grouped together. Thus if you’re needing to do something with smaller sets of backups and querying you’ll want to dig into how you separate things in to separate databases or schemas. As a broad rule 90% of applications have a cluster with a single database and single schema within them.

• Databases are useful when entirely isolated. If you have multiple different applications, but a small number of them so you’re not worried about scaling connections to each of them, then they’re a great method of separating your data access. For example, you could have a database for your blog, one for your events calendar, and one for your CRM application. All these are quite distinct and don’t interact with each other.

• Schemas can be useful for separating data that may otherwise follow the same table structure. In most cases you may not want to query across the full set of schemas, but for out of band reporting it could be useful. One of the most common practical applications of schemas is multi-tenant applications where you want to create a schema for user1, user2, user3. All the tables within those could look the same, but if you want analytical queries across your users you can easily do that.

The funny thing about jargon is how quickly we get used to it, and forget we are even using it. It becomes part of the secret handshake, the way we signal to other members of our tribe that we’re part of the group.

When I first started going to Postgres conferences and listening to talks by Postgres core developers I suddenly found myself at sea. What were these strange words and phrases they were using?

It turns out that a lot of them are taken from the Postgres code base, which in turn naturally uses them because they are part of Codd’s relational model, the theoretical information architecture that underpins all relational databases.

Here’s an unofficial, incomplete glossary of weird terms that come out of developers mouths when talking about Postgres.

I think often what’s going on with prompted agency is that it gives you permission to act, and many people aren’t good at acting without permission.

We grow up in very low agency environments. Between home and school, generally you aren’t able to exercise much agency without explicit permission to do so.As adults, we have much more permission to act autonomously, but we first have to unlearn the habits and emotional responses that we acquired when we didn’t.

This is an upcoming high performance computing book titled “Algorithms for Modern Hardware” by Sergey Slotin.

Its intended audience is everyone from performance engineers and practical algorithm researchers to undergraduate computer science students who have just finished an advanced algorithms course and want to learn more practical ways to speed up a program than by going from (n log n) to (n log log n).

Welcome to Operating Systems: Three Easy Pieces, a free online operating systems book! The book is centered around three conceptual pieces that are fundamental to operating systems: virtualization, concurrency, and persistence. In understanding the conceptual, you will also learn the practical, including how an operating system does things like schedule the CPU, manage memory, and store files persistently. Lots of fun stuff! Or maybe not so fun?

This is a quick view of incident models, as taken from various sources. I found this useful to go over a long while ago and then forgot what I did with my notes, so here’s new ones.

Do note that not all models are in precise orders. Some models have lived and evolved for decades and been influenced or borrowed from other models. The ordering here is arbitrary and as close to “first appearance” as possible, but not necessarily to “last time it was useful”.