标签: postgresql

我可以CASE用来选择在SELECT查询 (Postgres) 中显示哪些列，如下所示：

SELECT CASE WHEN val = 0 THEN column_x
            WHEN val = 1 THEN column_y
            ELSE 0
       END AS update, ...

UPDATE在 Postgres 中执行查询时是否有可能发生类似的事情（即选择应该更新哪些列）？我假设不是，因为我找不到任何关于此的信息，但也许有人有一个聪明的选择（除了使用过程或使用 a 更新每一列CASE来确定是否应为该列的值分配一个新值或简单地重新分配现有的价值）。如果没有简单的选择，我当然也会接受它作为答案。

额外信息：在我的情况下，我有 14 个可能的列可以更新，每个匹配行只更新一个（要更新的表与查询中的另一个表连接）。要更新的行数很可能会有所不同，可能是数十或数百。我相信加入条件的索引已经到位。

我刚开始使用 Postgres，我正在尝试创建一个示例数据库来了解它的功能，环顾四周，我在 pgfoundry.org 中找到了一些脚本。我理解这些命令，因为我之前同时使用了 Oracle 和 MS-SQL，但是我运行的所有脚本在到达“COPY FROM”指令时都返回错误。更准确地说，错误是在应该插入给定表中的第一个元素处抛出。

我已经尝试将脚本作为查询和 pgScripts 运行，但是在这两种方式中，我在 COPY FROM 之后的第一行都收到错误。

我正在使用 pgAdminIII，我使用 StackBuilder 将 PostgreSQL 9.2.4.1 安装为 DB 驱动程序。我是否可能缺少一些阻止我运行此命令的基本配置，或者我只是不明白他们的工作方式？

编辑：
错误是：

ERROR:  syntax error at or near "7"
LINE 5600: 7 4 13 37 2012-03-10 16:41:43.797787 2012-03-10 16:41:43.797...
           ^

********** Error **********

ERROR: syntax error at or near "7"
SQL status: 42601
Char: 140891`

文字在哪里：

COPY action_abilitations (id, group_action_id, partecipation_role_id, group_id, created_at, updated_at) FROM stdin;
7   4   13  37  2012-03-10 16:41:43.797787  2012-03-10 16:41:43.797787`

我正在尝试使用此命令作为 postgres 用户在 Fedora 18 中将 Postgresql 从 9.2 升级到 9.3

$ pg_upgrade -b /bin -B /usr/pgsql-9.3/bin -d /var/lib/pgsql/data -D /var/lib/pgsql/9.3/data/ -j 2 -u postgres

日志中的错误

命令："/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/pgsql/data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directory='/var/lib/pgsql'" start >> "pg_upgrade_server.log" 2>&1 等待服务器启动......致命：无法识别的配置参数“unix_socket_directory”......停止等待 pg_ctl：无法启动服务器

正如a_horse在评论中指出的那样，参数unix_socket_directories在 9.3 中被(plural)替换。但是正在启动的服务器版本是旧的9.2：

$ /bin/pg_ctl --version
pg_ctl (PostgreSQL) 9.2.4

有任何想法吗？

不久前，我花了噩梦般的几周时间来处理“检测到死锁”并试图找出如何处理它。我最终以这样的方式处理它：我的代码能够检测到它何时发生，然后无限期地重试相同的查询，每次重试之间间隔 50000 微秒，直到它起作用。

也许这是不好的做法，但到​​目前为止（几个月），除了记录“检测到死锁”所谓的“错误”之外，它还没有引起任何问题。

我现在可以通过将“检测到死锁”错误标记为“不重要”来抑制它们，从而不会向我显示，即使它们仍然记录到我的错误日志表中，这是否“可以”？

请不要告诉我“首先避免它们”。这根本不可能。如果您在同一个表/事物上并发（多个进程/脚本实例）工作，它们显然会发生。我花了很长时间试图“将它们编码掉”，但这似乎是不可能的。

显然，因为我问这个问题而不是仅仅添加忽略规则并完成它，所以我确实关心答案/响应。尽管如此，我认为目前还不能确信它们可以完全避免。我并不是说我每小时都会记录数千个记录，而是每天都会记录一些记录，似乎总是在一开始，当我确实有很多并发进程在同一个表/查询上工作时。

我正处于一个十字路口，我需要决定是否要坚持bigserial作为我的主键，或者更改为uuid（非自动生成\xe2\x80\x94）我的 API 服务器将使用 uuid v4 生成 ID并插入）。

我花了几个小时研究bigserial主uuid键，似乎没有人能就其缺点uuid（如果有的话）达成一致。jsonb我的数据库并没有那么复杂：它是一系列具有非常基本关系的表，我通常一次只插入一行，我到处使用一些字段。写入速度/频率只会在一张表上特别高。

我开始研究 UUID 的原因并不是因为我认为我会用完bigint密钥（如果我没记错的话，有 9 千万亿），更多的是从混淆的角度来看。现在我必须在前端对 ID 进行哈希处理，以避免在 URL 中显示用户数据库 ID（例如/things/2732）。使用Hashids，我可以使用类似 的 URL /things/To2jZP13dG。但我认为我可以更进一步，只使用 UUID，它不会提供有关记录数的任何线索。我不喜欢的是，在将 ID 传递到后端并在那里解码之前必须对其进行编码，然后在查询 50-100 个项目的批次以返回给客户端时，必须对所有这些进行批量编码，这会增加额外的工作量在将 ID 返回给客户之前。

支持随机 UUID（uuid v4）的一个论据是：

\n

如果您的主键是递增 ID，则它们在物理上彼此相邻存储。由于许多人正在写入该数据库页面，因此该数据库页面可能会发生争用。随机 ID 通过将写入分散到整个数据库来防止争用

\n

但后来我发现这里有一个矛盾的说法有一个矛盾的说法：

\n

常规随机 UUID 在整个可能值范围内均匀分布。这会导致在将数据插入索引时局部性较差 - 所有索引叶页都同样可能被命中，从而迫使整个索引进入内存。对于小索引来说这没什么问题，但是一旦索引大小超过共享缓冲区（或 RAM），缓存命中率就会迅速下降。

\n

我知道 Heroku 的人们热衷于使用 UUID 作为主键。不管它的价值如何，我根本不打算让 …

为什么PostgreSQL会顺序扫描表进行COUNT(*)查询，而有一个非常小的索引主键？

我有一个 PostgreSQL 9.5 服务器，上面有自动为用户创建角色和数据库的脚本。在这些数据库中启用特定扩展（例如 pgcrypto）会很有帮助，但据我所知，必须是超级用户才能运行CREATE EXTENSION. 有没有办法在不使用超级用户帐户手动登录的情况下启用此类扩展？

描述Postgres 10 新功能的页面提到了“触发器的转换表”。

触发器的转换表

此功能AFTER STATEMENT通过适当地向查询公开旧行和新行，使触发器既实用又高效。在此功能之前，AFTER STATEMENT触发器无法直接访问这些，并且变通方法是拜占庭式的并且性能很差。现在可以将许多触发器逻辑编写为AFTER STATEMENT，从而避免需要在 FOR EACH ROW 触发器所需的每一行进行昂贵的上下文切换。

什么是过渡表？

我在 postgres 文档中找不到对数据类型“名称”的任何引用，但我将其视为 pgagent.pga_jobstep 表中“jstdbname”列的数据类型。udt_name 也是“名称”。从该表中选择行会使它们看起来好像是字符串。

此处未列出：Postgres data types

• 我只想在一列中存储 3 个状态（如果是 2，我会使用布尔值）
• 我考虑过使用 ENUM('up', 'down', 'none') 但似乎 ENUM 占用了一些空间
• 有没有更好的方法在 PostgresQL 列中只存储 -1 0 和 1？