Saturday, August 18

Alvaro’s PlanetPostgreSQL

Talk slides: Partitioning Improvements in PostgreSQL 11

Alvaro's PlanetPostgreSQL, PostgreSQL
I spent a couple of days in São Paulo, Brazil last week, for the top-notch PGConf.Brazil 2018 experience. This year I gave a talk about improvements in the declarative partitioning area in the upcoming PostgreSQL 11 release — a huge step forward from what PostgreSQL 10 offers. We have some new features, some DDL handling enhancements, and some performance improvements, all worth checking out. I'm told that the organization is going to publish video recordings at some point; for the time being, here's my talk slides. I'm very happy that they invited me to talk once again in Brazil. I had a great time there, even if they won't allow me to give my talk in Spanish! Like every time I go there, I regret it once it's time to come home, because it's so easy to feel at home with the (more…)
Column Store Plans

Column Store Plans

2ndQuadrant, Alvaro's PlanetPostgreSQL, PostgreSQL
Over at pgsql-general, Bráulio Bhavamitra asks: I wonder if there is any plans to move postgresql entirely to a columnar store (or at least make it an option), maybe for version 10? This is a pretty interesting question. Completely replacing the current row-based store wouldn't be a good idea: it has served us extremely well and I'm pretty sure that replacing it entirely with a columnar store would be disastrous performance-wise for OLTP use cases. That doesn't mean columnar stores are a bad idea in general — because they aren't. They just have a more limited use case than “the whole database”. For analytical queries on append-mostly data, a columnar store is a much more appropriate representation than the regular row-based store, but not all databases are analytical. (more…)
Code coverage stats

Code coverage stats

Alvaro's PlanetPostgreSQL, PostgreSQL
Many years ago, Michelle Caise submitted a patch to generate code coverage reports for the PostgreSQL code base, based on the lcov utility. Although I cannot find any record of an actual patch in the mailing list archives, Peter Eisentraut committed it some time later, and applied further refinements later. Today I'm announcing a new PostgreSQL community service: code coverage reports generated automatically and updated daily using this infrastructure. I explain more details here (more…)

Managing a PostgreSQL Commitfest

Alvaro's PlanetPostgreSQL, PostgreSQL
If you've been following PostgreSQL development for the last few years, you've probably heard the term commitfest manager a few times.  You probably already know what a commitfest is, but why is there a manager? Since I spent a good deal of time this past January managing one, I'll explain. At its heart, a PostgreSQL commitfest is just a collection of patches awaiting integration into the PostgreSQL code base. A commitfest's working principle is that each patch that has been sent to pgsql-hackers must be reviewed timely; once reviewed and revised enough times, the patch is candidate for permanent inclusion into PostgreSQL by a committer. As for the commitfest workflow: each new patch starts life in the commitfest in “needs review” state; it can be closed as “rejected” ( (more…)