PostgreSQL 现在是一个完全成熟的数据库解决方案，应有尽有。它更像是一个以关系为中心的开发生态系统，而不仅仅是一个简单的存储和检索系统。
让我们来谈谈我们最喜欢的开源关系数据库。
如果你看一下这个项目的名称，你就会发现你需要知道的一切。以典型的 PostgreSQL 方式，你必须先了解所有内容，然后才能查看。让我们来解释一下。不，太多了。让我们总结一下。
早在 20 世纪 70 年代，关于“新数学”的讨论就非常热烈。新数学只是一种包装集合论思想的新方法。有一段时间，每个人都对它着迷，甚至孩子们也被教导通过组合苹果或棍子（或其他东西）的集合并相互比较来进行简单的算术。集合论在当时非常流行。
当时，一些数学家聚在一起，问自己（就像数学家经常做的那样）如何创建软件来回答以集合论形式提出的问题。结果是一种叫做 QUEL 的语言和一个叫做 GRE 的存储工具。我们将集中讨论 GRE 部分，它代表“图形检索引擎”。
你可能想知道它有什么图形化的东西，以至于这个词会出现在它的名字里。嗯，请记住，我们这里谈论的是 20 世纪 70 年代，我们仍然在谈论集合论。所以“图形化”就像一个非常早期的实体关系图 (ERD)。
也就是说，数据（集合）可以被说明为与其他数据（集合）的关系。啊哈！我们刚刚发现了为什么 PostgreSQL 团队仍然将数据集称为“关系”（而不是表、行或仅仅是数据）。
这种发展主要发生在加州大学伯克利分校的研究生项目中。在某个时候，我们所有的学生都毕业了，去了商业公司。其中一家是 Ingres，这家公司编写了一个数据库引擎（也叫 Ingres），它基于（你猜对了）GRE。“Ingres”的意思是“交互式图形和检索系统”。Ingres 在一段时间内很成功，并催生了几个商业分支，比如 Informix（和其他）。
20 世纪 80 年代的到来，伴随着个人电脑的出现和一些关于自由软件分发的想法。同一批开发者（主要是）创建了 GRE 的另一个实现，它出现在 Ingres 之后。鉴于早期作者奇妙的命名惯例（他们认为使用部分单词是对集合论的一种巧妙致敬），该项目被命名为“PostGRES”。也就是说，它是 Ingres 之后的系统，并且也是用 GRE 编写的。
在所有这些欢乐的同时，最初的 QUEL 语言也被重新引入，这次的绰号是“PostQUEL”。我们不知道你的感受，但我们现在笑得前仰后合。
然而，当时也出现了一种新的挑战者，挑战 QUEL 语言，它就是结构化查询语言 (SQL)，这个名字很有创意。这种新语言似乎比 QUEL 更灵活、更具扩展性，并且在其他数据库领域也有一批追随者。因此，在 1994 年，几个技术人员决定将其应用到 Postgres 项目中。
伙计，结果出奇地好。这种语言一直沿用至今，并且在 1996 年，Postgres 项目对其非常投入，以至于他们也将其应用到了产品名称中。
因此，我们有了最终的 PostgreSQL 项目名称，这个名称一直沿用至今。值得庆幸的是，这个名称中没有加上 XML、JSONB 和 BTREE。曾经有 人提倡这样做 😉。哎。
这取决于你是什么时候加入该项目的。最初的项目维护者根据最初的数据库或项目名称将其读作“postgrey”或“postgres”。有些人将其读作“postgress”（强调 ss）。这些人出现在 1994 年到 1996 年之间，可能不是核心开发人员。
1996 年之后，官方发音是“post-gress-queue-ell”。尽管这种发音是为了消除歧义，但它并没有像社区希望的那样流行起来。现在，大多数社区将其读作“post-grey sequel”，这是基于对该组合词的美式发音。
你如何发音主要取决于你是什么时候加入该项目的，以及你在加入该项目之前来自哪个方向。如果你想听起来像个元老级人物，那就说“post gress queue ell”。否则，你想怎么说就怎么说。看在上帝的份上，千万不要说“post gree”。
结构化查询语言，更广为人知的名字是 SQL，是你用来创建和使用某些数据库的语言。在 PostgreSQL 添加 SQL 语言的时候，它还相当原始（PostgreSQL 和 SQL 都是如此）。不过，这两个系统都展现出了巨大的潜力。
在 20 世纪 90 年代的大部分时间和 21 世纪初，PostgreSQL 项目致力于稳定性和基本功能。SQL 语言随着数据库功能的增长而扩展，反之亦然。
Postgres 项目在很大程度上仍然忠于其大学起源，并参与了许多关于 SQL 和数据库形成的设计讨论。事实上，今天仍然如此。PostgreSQL 在教育界有很大的影响力，并且在数据库相关主题的征求意见稿 (RFC) 中仍然有相当大的发言权。
但是，我们在故事中插入这段题外话是为了说明，在可预见的未来，SQL 仍然会存在。许多“简化”方案来了又去，每次的故事主线都大同小异。
有人会问：“我们怎样才能让 SQL 更简单呢？”答案是某种声明性语法，它可以轻松地显示基本的关系函数。10. 然后，数据库的复杂性现实就出现了，这种语法也被扩展了：转到 10。
在某种程度上，“简单”语法的复杂性与 SQL 完全相同。这是不可避免的，因为 SQL 语言的发展速度与数据库功能的发展速度相同。当你准确地描述了数据库的所有功能时，你就得到了 SQL 的一个克隆。
此时，这种新语法就变得无关紧要了，并与其他语法一起被扔进了历史的垃圾堆。
PostgreSQL 是软件和数据结构的组合，用于显示关系。然而，这个定义过于简练，有失公允。
在撰写本文时，PostgreSQL 已经由来自各行各业的数千名开发人员开发了 30 多年。因此，最初的定义仍然成立，但它掩盖了过去三十年中引入的复杂性。
除了基本功能之外，它现在还具有复制、外部数据、可插拔语言和索引。SQL 语言的实现已经发展了三十年，支持数据显示的算法数量也非常庞大。
正如我们在开头所说，PostgreSQL 现在是一个完全成熟的数据库解决方案，应有尽有。与其说它是一个简单的存储和检索系统，不如说它更像是一个以关系为中心的开发生态系统。
以下是 维基百科 上的一段简洁的描述：“PostgreSQL 的特点是具有 原子性、一致性、隔离性、持久性 (ACID) 属性的事务，可自动更新的视图、物化视图、触发器、外键和存储过程。[18] 它旨在处理从单台机器到具有许多并发用户的Web 服务或数据仓库的各种工作负载。它是 macOS Server[19][20][21][22] 的默认数据库，并且还可以用于 Linux、FreeBSD、OpenBSD 和 Windows。”
换句话说，它应有尽有。与其列举它拥有的所有功能，不如说它缺少哪些功能更容易一些。
单个查询的多处理还有很长的路要走。PostgreSQL 的每个版本都在改进此功能。在过去五、六个主要版本中，这是贡献最多的领域之一。
PostgreSQL 仍然基于单一摄取系统，也称为垂直可扩展。 分片和多节点设置要么是第三方提供的，要么根本不存在。
连接系统是基于进程的，而不是基于线程的。它基于这样一种理念，即 PostgreSQL 将被要求执行大量工作。因此，应该在相应的非统一内存访问 (NUMA) 处理器上为一个进程分配一个 CPU 和内存。让它尽可能长时间地待在那里，让它做它该做的事。这提供了很高的吞吐量，但可见性却很差。
PostgreSQL 没有很好的列数据存储功能。是的，有一些扩展可以缓解这个问题（cstore 和 hstore），但它们不是很流行。
当然，PostgreSQL 系统设计中也有一些东西缺失或存在固有缺陷。如果你想花点时间吐槽，可以阅读有关实现多版本并发控制 (MVCC) 的文档。把它当作一个喝酒游戏。每次文档中出现“这可能会有一些开销”时，就喝一口酒。这会让它变得更有趣。
PostgreSQL 维基百科主条目 对 PostgreSQL 的历史以及参与创建该产品的人员进行了很好的描述。你可以点击前一两段中的链接；那里有一些有趣的花絮。此外，你还可以阅读有关 QUEL 查询语言的文章。
此外，还可以参加会议。任何关于 PostgreSQL 的会议都可以，具体是哪个并不重要。大多数创新者仍然在，并且很乐意讲述 PostgreSQL 如何成为开源开发和社区典范的战争故事。
在那里见。
刚开始接触？了解如何修复 PostgreSQL 数据库中的常见错误
想充分利用 PostgreSQL？阅读关系数据库的联合创始人 Michael Stonebraker 如何 在他新的物联网商业投资中扩展 PostgreSQL。
