![](https://dataegret.de/wp-content/uploads/2024/05/Untitled-design-7-775x300.png)
Back from PGConf Belgium 2024
Last Tuesday (May 7, 2024) happened PGConf.BE in Leuven, Belgium. Living in Belgium myself, going to tech conferences in my own country is always a little bit special (and so much fun!).
While it was only the 4th time that the event was (very successfully) organized, and despite the attendance was not very high, this cozy conference still manage to have great line-up of talks every year!
(Previous years schedules for reference: 2019, 2022, 2023)
As opening talk, Pavlo Golub (Cybertec) told us about how they came to create the pg_timetable job scheduler for PostgreSQL. Briefly said, using system crontab doesn’t provide knowledge of the database specifics and using a scheduler directly inside PostgreSQL wouldn’t allow to easily perform system tasks. So they came up with this new tool, written in Go, to be able to support a variety of different platforms. Finally, Pavlo ended-up his talk with a quick demo on how to use the tool. Quite interesting tool IMHO.
Then Tomas Vondra (EDB), a very famous PostgreSQL hacker and committer, told us about performance cliffs: abrupt changes of performance for a given query, after only a small change in data and/or query parameters. In example, even if a query plan might look good, we could hit a performance cliff at runtime because of resource exhaustion: on-memory sort going to disk because the amount of data to sort doesn’t fit in the allocated memory. In this case, it is easy to understand how changing the selectivity of a query (estimated part of data to retrieve) is going to affect the query runtime but not the query planning. That’s also why unfortunately cost-base planning is often hard to correlate with query duration.
This specific example is usually mitigated by DBAs by raising work_mem or moving temp files to „in memory“ disks, but it doesn’t solve the underlying problem though.
The conference being held in a University, Tomas also wanted to add an academic side to his talk by raising some thoughts and possible improvements to research and investigate.
After the short coffee break, we had to choose between two talks. I decided to go see Priyanka Chatterjee (STACKIT) explain how to (not) use large objects in PostgreSQL. In summary, we today have TOAST which can transparently handle some specific data types (i.e. bytea) up until 1 GB. Despite pg_largeobject being able to handle way heavier elements, it comes with a big maintenance overhead: specific functions to manipulate the objects, tools to detect and remove the orphans (un-referenced),… In conclusion of this talk, the advice was to carefully think if you really have to store that big objects inside your database when object-stores are blooming in the Cloud.
After lunch, I obviously attended Ilya’s talk about Linux IO internals for PostgreSQL administrators, and Matt Cornillon’s (Aiven) talk about Pokémons and AI. I already had the chance to see those talks previously but it is always interesting to attend it again and see what changed since last time. For example, Matt also had a look at the latest features of pgvector which had a new release only 2 weeks ago.
Finally, we had a last break and I then stepped-up on stage to speak about PostgreSQL Recovery: Beyond Backup Basics (slides available here). I gave a talk here 2 years ago about how to achieve Point-in-time Recovery step by step, and this talk was kinda an extension of it. How to take backups is an area pretty well covered in PostgreSQL documentation, but I feel that users are usually more struggling with the recovery part. It is not always easy to understand all the settings involved there. If you missed the talk, we’ll be giving a webinar soon about this topic, so stay tuned 😉
Gianni Ciolli (EDB) concluded the day presenting the Trusted Postgres Architect tool. TPA is an orchestration tool that uses Ansible to deploy Postgres clusters, using a declarative approach. It also allows to install some other tools around Postgres itself (pgBouncer, Repmgr, Patroni, Barman), but not pgBackRest as far as I know 😥
As usually, it really was a nice conference, and the little reception after the talks at the end of the day allowed us to have many more interesting chats with the attendees and sponsors.
What’s next for me?
As I mentioned already, we’re preparing a new webinar about PostgreSQL recovery best practices and examples. But first, I’ll be speaking about pgBackRest Frequently Asked Questions at the PostgreSQL User Group NRW MeetUp next Wednesday (May 15) in Aachen and about Incremental Backups coming in PostgreSQL 17 at the Postgres User Group Frankfurt (am Main) on Thursday May 23.
I’m also quite excited to go to Vancouver (Canada) to attend PGConf.dev!
So, the usual question now, where will we see each other next? 🙂