#352 — April 22, 2020

Read on the Web

💬 We've got a neat bonus for you this week at the bottom of the issue 🙂

Postgres Weekly

Postgres Explain Visualizer 2: A Vue.js Component to Show Execution Plans — Less a standalone tool and something you’d use when building your own Postgres tooling. There is, however, a demo here. The output is really nifty.


Insert-Only Tables To Be Autovacuumed in Postgres 13 (But Why?) — Autovacuuming clears up dead tuples that are often left when updating or deleting data from tables, so why is autovacuuming for append-only tables a big deal in Postgres 13? Laurenz explains.

Laurenz Albe

Faster CI/CD for All Your Software Projects Using Buildkite — See how Shopify scaled from 300 to 1800 engineers while keeping their build times under 5 minutes.

Buildkite sponsor

Full Text Search in Milliseconds with Rails and Postgres — If you’ve never played with full text search with Postgres and Rails, this is a fine place to start. It covers LIKE/ILIKE, trigrams, and ‘proper’ full text searching. We also get to see how Leigh took a query from taking 130ms down to 7ms.

Leigh Halliday

An Easy Postgres 12 and pgAdmin 4 Setup with Docker — Docker provides an easy and loosely coupled way to get things set up in a development environment.

Jonathan S. Katz

Is There a Limit on Number of Partitions Handled by Postgres? — Sort of, but you’d really have to be going at it to stretch Postgres 12’s capabilities in this area.

Denish Patel

Where Do My Postgres Settings Come From? — A nice visual look at how parameters and settings cascade or override each other.

My DBA Notebook

Identify Slow-Running PostgreSQL Queries Quickly in Datadog — Improve PostgreSQL performance by visualizing and identifying errors fast using granular, out-of-the-box dashboards in Datadog.

Datadog sponsor

Replicate Multiple Postgres Servers to a Single MongoDB Server using Logical Decoding Output Plugin

David Zhang

An Overview of the JOIN Methods in Postgres

Kumar Rajeev Rastogi

Luca Ferrari has had a huge impact on the Postgres community in Italy, having been president of the Italian PostgreSQL Users Group in the past and having helped to organize the popular PGDay.it events. He also blogs frequently about Postgres and wrote PostgreSQL 11 Server Side Programming Quick Start Guide for Packt.

Note: A more complete version of this interview is on the Web.

We caught up with him to ask about server side Postgres use cases in particular:

For those who use Postgres as a simple database and haven't touched the deeper elements, where do you think they should start?

There's no single answer to this question, since Postgres is such a huge project with so many features and a rich community. I never found a project where it cannot fit in. Postgres is somehow like Unix: you cannot touch it as "just a database", you need to commit to its culture to benefit the most out of it.

In my classes, I can see that people usually get fascinated by the capabilities of doing server side programming, and that is why I decided to write my book about this topic. Often, people do not expect to be able to embed their Perl, Java, or Python libraries directly into PostgreSQL without having to rewrite their business logic in an SQL-like language.

Another great feature nowdays is the support to JSON within the database, thanks to which PostgreSQL can be used as both a relational database and a 'NoSQL' storage engine, providing a lot of flexibility in your infrastructure.

One suggestion I always gave is to join the mailing lists: there are several that differ by topic and amount of traffic. Most are very active and have high quality contributors that take care in providing accuate replies to users' questions, that spend time in reproducing errors and edge-cases, and who will help you. That's a mandatory place where you have to start, in my opinion, to better learn about the project, its features and its culture.

Where should the line be drawn between doing things in an external programming language versus within Postgres?

Often the right choice is to place business logic near the data it refers to, that is within the database itself. However, there are several things to take into account including the developer's experience and the expressiveness of SQL-derived languages like pl/PgSQL.

There's a habit of letting ORMs (Object Relational Mappers) do most of the database interaction nowadays, reducing the database to a "simple storage". Of course, databases can do a lot more, and PostgreSQL in particular can help you migrate and embed your own business logic into the database itself.

I have helped a few companies embed their own Java libraries into Postgres resulting in a more robust and coherent way to access the data (the real value) without any regard of the application they were using. Because once you start having data, you will soon find that such data is required by multiple applications in different technologies and on different platforms, so that implementing the same business logic rules over and over becomes a huge effort; on the other hand, moving such logic within the database simplifies and keep uniform the way your data is manipulated.

What one thing do you think people should learn?

Stored procedures. They serve as a common base for triggers and are very similar to routines, therefore allowing you to build more complex pieces into your own cluster. Once you have learnt the common way of defining functions, you can go deeper and write your own native functions using other languages (e.g. C). This is more complex, but thanks to the extensibility of Postgres is not an impossible task and can help you migrating more and more code into the database. Once you have created a new feature, please do contribute it back so that other people can use it!


Last, allow me to announce that I'm working on another book right now: me and a friend of mine are writing a more general book on Postgres that will try to answer your question by leading the reader through the main features that make Postgres unique and great.

Be sure to check out Luca's book PostgreSQL 11 Server Side Programming Quick Start Guide to learn more about the topics covered in this interview. You can also find the code from the book in this GitHub repo.

If you enjoyed this interview, Luca actually gave some more detailed answers in the full interview which you can read here.