rhaas

The infrastructure is intentionally pluggable to facilitate different viewpoints on questions like this. I hope we see various add-on modules pop up that fetch advice strings from various possible sources.

I agree that for many use cases, standbys and in particular time-delayed standbys are a better option than backups. That said, having off-line backups in tamper-proof storage is a good call, too.

I have been a PostgreSQL hacker since 2008 and a PostgreSQL user for many years before that. The first mention of my name in the PostgreSQL commit log is in 2003, and the first version of PostgreSQL that I used was 7.something; it couldn't drop columns yet.

Now that doesn't mean that I know every person who does good work on behalf of PostgreSQL, but it does mean that I expect to recognize the names of most people who have been involved in the project to a significant degree. And the only one of those names I recognize is yours.

I tried a quick Google search of each name with "site:postgresql.org" and the only one of those names that gets any hits is, again, yours. That means that, as far as Google knows, not a single one of those people has posted even a single message to any PostgreSQL mailing list ever. Needless to say, that's not close to true for any current member of the PostgreSQL core team, or a vast number of people who are not on the core team but who are involved in the project to greater or lesser extents.

It is true that the PostgreSQL community is distributed, and not everything happens or is required to happen on postgresql.org. But I think it is nevertheless extremely difficult to argue that a group of people who have never posted there even once are a more legitimate group to be in charge of PostgreSQL's trademarks than the PostgreSQL core team.

The only name I can find on the "Fundación PostgreSQL" web site is yours. The PostgreSQL core team membership is listed on postgresql.org and includes 7 members from 4 different companies. I agree that perhaps the PostgreSQL core team could and should have more diversity than it does, and not just in terms of who employs them ... but an organization with only one publicly-disclosed member is not somehow better.

I wrote a previous post on why MVCC is interesting, and how it relates to the topic at hand. It's the first link in the article.

I don't think that it's accurate to say to say that there are only two ways of doing this. There are more than two, and there's another post by my colleague Amit Kapila which talks about that. That's the second link in the article.

We have in fact done benchmarks. We plan to publish them.

But you can't put everything into one article. Several people mentioned thinking this one was quite long, and it barely scratches the surface of the topic. If I'd included an in-depth discussion of all the topics you raise here, it would have been four or five times longer. To try to avoid that, yet give the context you want, I linked to previous posts which cover this topic, some of which were written explicitly to provide context for this article.

But I'm sorry you didn't like the article. I tried my best.

Uh, indexes in postgres point to the tuple, not the page.

Except for BRIN.

The first release of PostgreSQL that had synchronous replication was released in September 2011.

https://www.postgresql.org/docs/9.1/static/release-9-1.html

The work that has been done on transition tables is intended to enable future work on automatically updated materialized views; the idea is that the system will automatically derive a query to update the view based on the deltas between the set of old rows and the set of new rows. That will take more work, though. I do agree it would be valuable. It's possible to set up similar things by writing your own triggers, and having transition tables available in PL/pgsql will make it easier, but it's not necessarily easy to figure it all out by hand for a complex view involving joins and aggregates.

I agree with you that stored procedures are superior to client-side logic, because it means that you can have multiple routes of access to the database and all of them enforce the same business logic. But what exactly do you mean by "more basic data structures"?

Replication across major versions, for example to upgrade without downtime. Partial replication, to distribute shared data across a series of clusters, or for analytics and reporting as you mention. Replicating the data without replicating any table bloat. Being able to do limited writes (e.g. to temporary tables) on the standby. http://rhaas.blogspot.com/2011/02/case-for-logical-replicati...

I hope that it will have that effect. We need a few other features first: partitionwise join, partitionwise aggregate, asynchronous query, and ideally hash partitioning.

Yep, see http://rhaas.blogspot.com/2010/11/mysql-vs-postgresql-part-1...