小编Erw*_*ter的帖子

PostgreSQL 中最快的查询是什么，我可以将其用作绑定 JNDI 资源的验证查询？

我认为这SELECT 1是最简单的，但在本文档中说在 PostgreSQL 中我们应该使用select version(). 这对我来说并不明显。

我试图进行比较EXPLAIN ANALYZE SELECT 1，EXPLAIN ANALYZE SELECT version()但仍然不明白为什么第二个（或应该）更快。

在数据库中存储单个记录的元数据的最佳实践是什么？

我需要在我的数据库中存储许多表的常见元数据，例如创建时间和上次更新时间。我找到了几种不同的解决方案：

1. 将元数据直接存储在表中。

   优点：

   • 元数据直接链接到记录
   • 无需连接即可检索元数据

   缺点：

   • 需要大量重复列（除非使用继承）
   • 元数据和业务数据不分离

2. 创建一个通用元数据表，并使用软外键将数据链接到正确的表和记录。

   优点：

   • 没有重复的列
   • 元数据与业务数据分离

   缺点：

   • 元数据和数据之间没有直接链接（不能使用 FK）
   • 联接需要附加条件

3. 为每个需要元数据的表创建单独的元数据表。

   优点：

   • 元数据直接链接到记录
   • 元数据与业务数据分离

   缺点：

   • 需要很多额外的表
   • 需要大量重复列（除非使用继承）

是否有比我在这里提到的更多的选择、优点或缺点？存储这些元数据的最佳实践是什么？

我需要从另一个表更新一个表，我需要更新所有列。除了列出SET子句中的每一列之外，有没有办法一次更新它们？像这样：

update tableA
set * = tableB.*
from tableB where tableA.id = tableB.id

我在 psql 中尝试过，它不起作用。我必须像这样列出每一列：

update tableA
set c1 = tableB.c1, c2 = tableB.c2, ...
from tableB where tableA.id = tableB.id

tableB创建使用create .. like tableA. 所以它们基本上是相同的。我这样做的原因是我需要将 .csv 数据加载到临时表tableB，然后tableA根据.csv 中的新数据进行更新tableB。tableA需要尽量少加锁，tableA需要保持完整性。我不确定“删除然后插入”是否是一个不错的选择？

我按照两个教程创建了一个数据库：

1. 一个完全特权的用户链接
2. 只读用户链接

然后我从CJ Estel 的教程中得到了一条提示，指出“即使我们从未明确将其提供给我们的新用户，您也可能继承了创建表的能力”。果然，只读用户能够创建和拥有表！

CJ Estel 很好地指出了根本原因，即模板数据库。但是，创建表格的能力破坏了您通过谷歌搜索“只读用户 postgres”获得的大多数教程，包括在 postgresql.org 上托管的教程。您的用户拥有的不仅仅是只读权限！

为什么新用户有这种能力？撤销此权限后，该用户的数据库是否真的是只读的？

由于pg_catalog架构中的对象隐含在search_path( docs ) 中，是否建议在该架构中安装扩展？

我正在阅读 postgresql 教程，我创建了我的数据库、2 个表、天气和城市，并添加了几行数据。例如，当我使用此 sql 语句查询我的数据库时：

SELECT city, temp_lo, temp_hi, prcp, date FROM weather;

我应该得到这个：

     city     | temp_lo | temp_hi | prcp |    date
--------------+---------+---------+------+------------
San Francisco |      46 |      50 | 0.25 | 1994-11-27
San Francisco |      43 |      57 |    0 | 1994-11-29
Hayward       |      37 |      54 |      | 1994-11-29
(3 rows)

但我明白了：

San Francisco |      46 |      50 | 0.25 | 1994-11-27
San Francisco |      43 |      57 |    0 | 1994-11-29
Hayward       |      37 …

Postgres 新手在这里。

我想知道这个查询是否经过优化？我试图仅加入 100% 必要的值，并将所有动态条件留在 WHERE 子句中。见下文。

SELECT *
    FROM
      myapp_employees
    JOIN myapp_users ON
      myapp_users.user_id=myapp_employees.user_id
    JOIN myapp_contacts_assoc ON
      myapp_contacts_assoc.user_id=myapp_users.user_id
    JOIN myapp_contacts ON
      myapp_contacts.contact_id=myapp_contacts_assoc.contact_id
    WHERE
      myapp_contacts.value='test@gmail.com' AND
      myapp_contacts.type=(1)::INT2 AND
      myapp_contacts.is_primary=(1)::INT2 AND
      myapp_contacts.expired_at IS NULL AND
      myapp_employees.status=(1)::INT2 AND
      myapp_users.status=(1)::INT2
    LIMIT 1;

注意：对于上下文，此过程正在检查用户是否也是员工（提升的权限/不同的用户类型）。

无论如何，这是正确的方法吗？例如，JOIN ON 是否应该包含更多语句，例如检查 expired_at IS NULL？为什么或为什么这没有意义？

我有很多看起来像这样的表格：

CREATE TABLE table1(id INTEGER PRIMARY KEY, t1c1 INTEGER, t1c2 INTEGER);
CREATE TABLE table2(id INTEGER PRIMARY KEY, t1 INTEGER REFERENCES table1(id), t2c1 INTEGER);

我做了很多连接，我试图过滤连接表以从第一个表中获取内容，如下所示：

SELECT t1c1
FROM table1
JOIN table2 ON table2.t1 = table1.id
WHERE t2c1 = 42;

当我为表编写索引时，我会查看 WHERE 子句中使用的列并构建索引以满足它们。所以对于这个查询，我最终会写一个这样的索引：

CREATE INDEX ON table2 (t2c1);

并且这个索引至少有资格在该查询中使用。

我的问题是，如果我写这样的索引：

CREATE INDEX ON table2 (t2c1, t1);

索引会不会作为覆盖索引来帮助上面查询中的JOIN？我应该改变我的索引编写策略来覆盖外键列吗？

Microsoft SQL Server 有一个我认为非常明智的函数，如果转换不成功，try_cast()它返回一个null，而不是引发错误。

这使得可以使用CASE表达式或 acoalesce来回退。例如：

SELECT coalesce(try_cast(data as int),0);

问题是，PostgreSQL 有没有类似的东西？

提出这个问题是为了填补我知识中的一些空白，但也有一个一般原则，即有些人更喜欢对某些用户错误做出不那么剧烈的反应。null在 SQL 中返回 a比错误更容易。例如SELECT * FROM data WHERE try_cast(value) IS NOT NULL;。根据我的经验，如果有 B 计划，有时可以更好地处理用户错误。

我有一个在 Postgres 上运行的大小合适（约 50k 行）的时间序列数据库，还有一些其他结构化数据（在另一个数据库实例中）要小得多。

愚蠢的是，当我最初设计这个东西时，我把所有的字段都作为TIMESTAMP WITHOUT TIME ZONE，现在我用恼人的时区相关的错误来支付它。我希望一切都是明确的，所以想将字段转换为TIMESTAMP WITH TIME ZONE. 我意识到这不会存储额外的信息，并且我所有的时间戳都已经在 UTC 中，所以迁移应该是微不足道的，但我想知道是否有任何复杂的事情/潜在的绊倒块会证明有问题（这是一个生产客户依赖它的数据库）？