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.
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 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.
Postgres is not only about code. It's a Community. Contributions are more than code.
We value team membership by their abilities, and values. Those may prove better at building Community that C programming ability.
Yet you are wrong when you state that Core Team holds trademarks. Core is not even a legal entity (the main mistake that I've been voicing for years; it should).
Instead, there's a "loosely associated" association in Canada (PAC), with a governing board as opaque as Core, that holds the trademarks. Let's even assume this is OK.
But then, PEU (https://www.postgresql.eu/) also holds trademarks! Why? Is PEU an "official" association in any way? (if so, there should be a process and rules to become official, but there aren't).
So if Core (read: PAC) is the only one who should hold the trademarks, why is not Core/PAC also suing and publicly bashing against PEU? What makes PEU special? What makes legally PEU different from other Postgres NPOs?
I've been asking this question for years, including many times during this "debate" with Core/PEU/PAC about the trademarks. No answer.
No, I mean the "rules" that would enable a NPO to be able to hold IP for the project. There are no rules for that, yet PostgreSQL Europe holds trademarks and domain names for the PostgreSQL project.
And nobody has asked them, neither sued them, for this. Indeed, PostgreSQL Europe joined together with Canada to sue Fundación.
But PostgreSQL Europe is no different from Fundación: just a Postgres NPO.
PGEU is directly affiliated and acknowledged by the PostgreSQL community, whereas Fundación is not. This can be seen by the absence of Fundación on the donations page (where PGEU is listed), the lack of mailing list for Fundación (general-eu is maintained by or allocated for PGEU), and it is missing from IRC/external webpages/Local User Groups pages (#postgresql-eu is under management of PGEU). As such, you should not call Fundación a "Postgres NPO", as it is unaffiliated with the main PostgreSQL project.
Furthermore, Fundación does not seem to have a fair and transparent method for the community to get involved; instead of association members voting for the board (Patronage) the board seemingly appoints their own members (Art. 10(2) of Statutes). Lastly, Fundación has no well-defined trademark policy (only fair use, so I would be unable to start my local PostgreSQL Community (Netherlands) without infringing on the trademark).
PGEU however is transparent in who can become a member (~anyone in Europe), how the board is elected (popular vote by all members of proposed member candidates) and clearly describes in what conditions these brands may be used other than the normal fair use policy.
> PGEU is directly affiliated and acknowledged by the PostgreSQL community, whereas Fundación is not.
But that just begs the question[§], doesn't it: So how does one become "affiliated and acknowledged"; why is it that PGEU is and Fundación is not? (AFAICS ATM: Cronyism, pure and simple.)
___
[§]: Unless it doesn't; I can never remember how that weird expression works.
That page directly answers your question? It says "To become recognised as an NPO, the organisation must self-certify that they meet the criteria below, aimed at ensuring they meet the standards of openness expected in the PostgreSQL Community". The Fundación refuses to meet the standards outlined in this document, for example the standard that "The board of directors MUST be elected by the membership, and all members including any corporate members MUST have an equal vote."
(The page in question then also goes on to say "The PostgreSQL Core Team may recognise, not recognise, or rescind a previous recognition of any organisation without justification, regardless of whether or not the criteria above are met.", but that's irrelevant here because the baseline requirements are not even met)
What "that" page? Aha, the page linked from the five comments up-thread... If it's as well hidden on the site -- which I'd say it is, linked as it is from a page with the semi-unrelated title ans subject of "Donate", and lacking an entry of its own in the tree on the left -- as in the comments here, then no wonder ahachete maybe just couldn't find it.
And either way, it still doesn't answer ahachete's question:
>>> So if Core (read: PAC) is the only one who should hold the trademarks, why is not Core/PAC also suing and publicly bashing against PEU? What makes PEU special? What makes legally PEU different from other Postgres NPOs?
Sure, so PGEU is apparently "acknowledged as affiliated". But where does it say that this confers rights to use the trademark, and anything else doesn't? Is this "affiliation acknowledgment" a concept in trademark law; and if so, is that Spanish, EU, US, or international trademark law? (I very much doubt it features in any of them.)
>>> I've been asking this question for years, including many times during this "debate" with Core/PEU/PAC about the trademarks. No answer.
It's great that you pointed me (albeit indirectly) to that page of criteria, but maybe the people ahachete asked could have done the same for him.
> The page in question then also goes on to say "The PostgreSQL Core Team may recognise, not recognise, or rescind a previous recognition of any organisation without justification, regardless of whether or not the criteria above are met.", but that's irrelevant
Oh, I don't know that it is all that irrelevant, at least in a larger context. Quite apart from ahachete's tribulations: Are all contributors aware that they've donated their efforts to be so capriciously allowed -- or not, as the case may be -- to be traded upon by others, and apparently without recourse to any due process?
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.
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 wonder why not to go for a changelog-based implementation. Instead of modifying the materialized view directly, write the changes into a changelog, and then update the matview in the background. More efficient, less locking issues, etc.
How do you know when the change will affect the matview? I don't know the syntax for creating it off the top of my head, but imagine a materialized view limited to the top ten records of a table.
Hopefully, some of those restrictions will disappear, because matviews are often used to store pre-aggregted data, so the restriction on GROUP BY would be unfortunate.
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"?
PL/SQL has various types of collections, for example, that are super-useful when you need to do more complicated processing without having to create temporary tables and such.
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...
Indeed--anything where you want the secondary to be other than a bit-for-bit copy of the primary. It's also convenient for HA in some cases due to the fact that the DBMS copies are fully independent, hence free from propagated bit-level errors and also available for unimpeded reads.
MySQL started with logical replication very early on and it has proven extraordinarily useful. One of the more interesting use cases is feeding log transactions into data warehouses, which should be possible in PostgreSQL 10.
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.
