Direct naar content

Time to sharpen the axe

Our DBA consultants and Database specialists prefer to be working for our customers on site or remotely to help with (open Source) database management systems such as design, benchmarking, maintenance and support.
But sometimes it also makes sense to “grind the axe.”
Open Source products are evolving at lightning speed, partly because so many people worldwide are working on them, which is why our DBAs also like to spend a few days brushing up. Where better to do that than at international open source database conferences.
In this blog, our own Bernard Verheij tells us what he learned there.

PostgreSQL conferences

PostgreSQL is a relational open source database that can now easily rival major licensed database platforms such as Oracle and Microsoft SQL Server. More about Postgres is described in this blog: An expert’s view of PostgreSQL.

PostgreSQL is not developed or managed by a single company, but relies on a global community of developers and DBAs. The advantage for the user: no large, complicated (and expensive) licensing structures, and for those who want one: a worldwide network of committed IT professionals who put their heart and soul into optimizing database software. You can read more about open source community here.


There are quarterly national meetups that we organize together with the PostgreSQL Usergroup NL and also there are several conferences every year, worldwide, where we discuss what is included in this year’s new release and of course all kinds of use cases, tips, tricks in and around the PostgreSQL database.

If you as a DBA or developer want to keep up to date in a fun way, such a conference is a great opportunity to be updated by enthusiastic peers. Everyone can contribute in his or her own way to the PostgreSQL open source database.

Performance Tuning

I myself benefited very much from the Performance Tuning training offered at the London conference by a senior contributor, a very subject-oriented and technically substantive training that took me through Postgres Tuning.

For example, when you are a DBA installing a database at a customer’s site, one of the first things you have to do is: tune the default settings.

The database needs to optimally match the existing configurations, and specific queries that occur frequently need to be processed optimally so that users don’t have to wait half an hour for the data they request. Good performance tuning must be tuned to the entire IT architecture, and it is different everywhere: is a database local, in the cloud, partially in the cloud, in a cluster, with replication, or is it distributed across all kinds of different servers?

The PostgreSQL training Performance Tuning covered a number of components:

  • VACUUM Freezing & Avoiding Wraparound
  • Explain and SQL Execution
  • Workload Analysis


In addition to Performance Tuning, a database also needs maintenance. A database is an organic whole. Data is added, changed, deleted. But when employees delete data, it does not mean that the datapages in the database are deleted. In fact, it usually doesn’t. This can leave awkward empty spaces in the datafiles in all sorts of places on the hard drive that can make a database slow.

How can you prevent this from happening? When can you tell this maintenance is needed? That, too, was covered during the PostgreSQL Performance Tuning training. So you can do proactive checks where performance problems occur, either automated or manual. You can also write your scripts to check the database.

Using cases, the trainer explained what was possible and participants could also ask their own questions. It was very nice to get together in London with all the professionals. Because there were all kinds of speakers who all highlighted a subject related to PostgreSQL, you hear in a very short time a very broad overview of topics that you may have to deal with.

From a different perspective, the training went over a number of topics that were also covered in the PostgreSQL certification.

Now when I’m with a client I can take all that with me.

What’s ahead?

Finally, at the conference, we were also updated on new and updated features coming together in the new release PostgreSQL 12.

For me, the most important innovation was the new Recover.signal trigger file – an updated version of Recover.conf, which eliminates the need to use your own scripts to manage your database.

There were also a few improvements developed around Partitioning within PostgreSQL, which now allows tables to be distributed across multiple disks even more conveniently, giving end users a better