dba

graph TD A["User Process (PostgreSQL Backend)"] --> B{"Virtual Address Space (Backend)"}; B -- Accesses Data --> C["Shared Memory Segment (Mapped into VAS)"]; C --> D{"Shared Buffers (Within Shared Memory)"}; D -- Holds Data from --> E[PostgreSQL Data Files on Disk]; subgraph "Virtual Address Space (Backend)" B1["Process Private Memory (work_mem, etc.)"] B2["Shared Memory Segment (for shared_buffers)"] B --o B1 B --o B2 end style B fill:#ccf,stroke:#333,stroke-width:2px style C fill:#9cf,stroke:#333,stroke-width:2px style D fill:#cff,stroke:#333,stroke-width:2px style E fill:#eee,stroke:#333,stroke-width:2px style A fill:#fff,stroke:#333,stroke-width:2px

When a table is designed the columns have an order that follows the human logic that doesn’t necessary gives coincides with the way PostgreSQL stores the data ad may cause unnecessary bloat.

Let’s find out why the column order is important and how we can use it to improve our storage and consequently get better performance.

In the previous blog post we have seen how plenty of ram doesn’t necessary results in a faster instance.

This time we’ll quickly see how PostgreSQL and Linux relate to each other in particular if we want to run our RDBMS at scale.

Then we’ll have a look to the virtual memory in Linux and how to make it more friendly to PostgreSQL.

Let’s dig in.

Nowadays it’s not uncommon to deal with machines with hundreds of GB of RAM.

Abundant memory can give PostgreSQL a massive performance boost. However things work slightly different than you may expect.

Let’s find out!

Back in 2020 at the FOSDEM PGDay I discovered how the public schema’s permissions were far too permissive.

In any PostgreSQL up to version 14 any logged user could create relations or functions in the public schema posing a concrete risk for the database security.

In this post I want to recollect the thoughts about the issue, how to fix it and why it shouldn’t be ignored even if the instance has been migrated to a PostgreSQL version in theory not affected by the problem.

Again there is another pretty long hiatus.

Thing happens and independently from how bad my childhood was, family comes first.

Anyway after a rollercoaster ride that started in July 2021 things are getting more stable.

Has been a long time since I wrote on my blog. The paths that life decides for you are strange. Often what you planned is completely scrambled by something bigger and completely unforeseen.

Back in 2018 I planned to relocate to France but the move went quite wrong for reasons that only now I can see clearly.

Anyway, finally after 10 months wandering without a real home I’m finally settled down somewhere.

Then this is is the perfect occasion to celebrate the second database administrators appreciation day.

Back in 2018 I launched the event because there were no day dedicated for this obscure and yet very important figure within the enterprises.

Therefore don’t forget 5th of July, it’s the day when you should say thank you to your DBA for all of the hard work.

Database administrators usually work behind the scenes, over the weekends and in antisocial hours. They strive to look after the database which is at the core of any business with little or no recognition.

The sad truth is that the DBA is one of the most obscure and one of the less appreciated roles within the IT organisations.