Wednesday, August 16

Author: alvherre

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…)