This site is about a previous instance of this event. For the current event, please see the updated site.

Speaker photo for Matt Pearson

Interview with Matt Pearson

Talks

Social Media

Could you briefly introduce yourself?

I’m a Database Consultant at Pythian where I specialise in PostgreSQL. I’m based mainly in the UK, working from my home town of Bristol, situated in the south-west of England.

I have several hobbies and interests including cycling, reading and history. I love travelling to other countries to visit ancient archaeological sites and trying to understand the challenges that these civilizations faced.

How do you engage with the PostgreSQL Community?

I’ve written a couple of blogs on various subjects and I keep an eye on the forums, although it is mostly just browsing them. This will be my first talk at a PostgreSQL EU event.

Have you enjoyed previous PostgreSQL Europe conferences, either as an attendee or as a speaker? (PGConf.EU, FOSDEM PGDay, Nordic PGDay, pgDay Paris, PGConf.DE)

I have not attended any conferences in the last few years. There was a conference in London, which I attended, which was the first one since the pandemic.

What will your talk be about, exactly? Why this topic?

The talk is about what type of backup tools are available for DBA’s to use. There are a lot of competitors and which should be used in what situation and why? Also, what is best practice for a backup? Not all solutions are the same and maybe a full backup is not always warranted or needed depending on the case. However, I have seen several systems without continuous backups, so I want to highlight what should be standard practice in the PG community, namely setting up continuous backups on Production databases.

What is the audience for your talk?

I think this will interest anyone who cares for data integrity. So, obviously DBA’s will want to take note but System Administrators may also want to see why we need to do more than just backup the filesystem. And managers and auditors should have an appreciation for backup and recovery strategy, especially when the audit arrives or the worst case scenario happens and the database cluster has to be rebuilt. An understanding of principles and technology can save a lot of time and questions.

What existing knowledge should the attendee have?

I’m aiming this talk at a basic level, so there is no need to have in-depth knowledge of PostgreSQL but an understanding of backup and recovery principles is advised. along with the knowledge of what a database is and the different types of backups available, although I plan to cover that in the presentation.

What is the one feature in PostgreSQL 15 which you like most?

In logical replication, allowing the WHERE to filter data for the publications. This can help push the data that is needed and can save on space. Also, different data could be published for different subscribers, potentially breaking multi-tenant databases up into constituent parts. It is a fairly niche use-case but one that I can already see a use for.

Which other talk at this year’s conference would you like to see?

There are a few talks that I’m looking forward to. The Timescale presentation looks intriguing and the one on materialised CTE’s is a subject that I’d like to know more about. I’m going to miss the Ora2PG talk, which is always a hot topic in my world but I’m looking forward to the talks on tracing which has piqued my interest.

Which measure, action, feature or activity would—in your eyes—help to accelerate the adoption of PostgreSQL?

As an old Oracle DBA, I want to see better metrics for PG. We don’t have anything nearly as comprehensive as AWR or ASH. While we have some extensions that can help, they don’t come as standard and they don’t measure the metrics well enough, in my opinion.

When are we going to get a standard certification path for PG open-source?

I don’t know when this might be addressed but having an open-source certification path would help the adoption of PostgreSQL standards and show what should be best practice in the community.