We seldom credit patch reviewers. I decided to pay a little homage to those silent heroes for a few of them: here's the list of people who were credited as having reviewed the patches mentioned in my previous article for PostgreSQL 11. The number in front is the number of times they were credited as reviewers.
Amit Langote, Robert Haas
Dilip Kumar, Jesper Pedersen, Rajkumar Raghuwanshi
Amul Sul, David Rowley, Rafia Sabih, Simon Riggs, Thomas Munro
Antonin Houska, Ashutosh Bapat, Kyotaro Horiguchi
Álvaro Herrera, Amit Kapila, Amit Khandekar, Etsuro Fujita, Jaime Casanova, Keith Fiske, Konstantin Knizhnik, Pascal Legrand, Pavan Deolasee, Rajkumar Raghuanshi, Rushabh Lathia, Sven Kunze, Thom Brown, Yugo Nagata (more…)
A partitioning system in PostgreSQL was first added in PostgreSQL 8.1 by 2ndQuadrant founder Simon Riggs. It was based on relation inheritance and used a novel technique to exclude tables from being scanned by a query, called “constraint exclusion”. While it was a huge step forward at the time, it is nowadays seen as cumbersome to use as well as slow, and thus needing replacement.
In version 10, it was replaced thanks to heroic efforts by Amit Langote with modern-style “declarative partitioning”. This new tech meant you no longer needed to write code manually to route tuples to their correct partitions, and no longer needed to manually declare correct constraints for each partition: the system did those things automatically for you.
Sadly, in PostgreSQL 10 that's pretty much (more…)
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…)
I just committed a patch by Pavel Stěhule that adds the XMLTABLE functionality to PostgreSQL 10. XMLTABLE is a very useful feature dictated by the SQL/XML standard, that lets you turn your XML data into relational form, so that you can mix it with the rest of your relational data. This feature has many uses; keep reading for some details on it.
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.
PostgreSQL's Release Management Team is requesting your input on patches that are most likely to cause bugs or instability. I'm sure you have an opinion on that! Please cast your votes by filling this form.
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…)
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…)