标签: postgresql

我有一个奇怪的情况，从日志中看到：

Process 37278 waits for ExclusiveLock on advisory lock [16421,999999,12864385,2]; blocked by process 53807. 
Process 53807 waits for ExclusiveLock on advisory lock [16421,999999,12864395,2]; blocked by process 37278. 
Process 37278: SELECT * FROM zel_api.insert_event ($1 ,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24) 
Process 53807: SELECT * FROM zel_api.insert_event ($1 ,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24)",
"See server log for query details.",,,"SQL statement ""SELECT pg_advisory_xact_lock(999999, format('zel_event.%I', p_table_name)::regclass::oid::integer)""

这本身就已经很奇怪了，因为看起来两个进程阻塞了同一个咨询锁，但实际上都不能抓住它。

尝试获取锁的函数如下：

CREATE OR REPLACE FUNCTION zel_event.create_new_partition(
    p_table_name text
)
RETURNS void AS
$BODY$
DECLARE
    _schema text;
BEGIN
    IF NOT EXISTS (table from catalog)
    THEN
        PERFORM …

我们使用 Postgres 进行分析（星型模式）。每隔几秒钟，我们就会收到大约 500 种指标类型的报告。最简单的模式是：

timestamp      metric_type     value
78930890       FOO              80.9
78930890       ZOO              20

我们的 DBA 提出了一个建议，将所有相同 5 秒的报告展平为：

timestamp   metric1     metric2     ...  metric500
78930890    90.9        20          ...  

一些开发人员反驳这种说法，称这增加了开发的巨大复杂性（批处理数据，以便一次性编写）和可维护性（仅查看表或添加字段更复杂）。

DBA 模型是此类系统中的标准做法还是仅在原始模型显然不够可扩展时的最后手段？

编辑：最终目标是为用户绘制折线图。因此，查询主要是选择几个指标，按小时/分钟折叠它们，然后选择每小时（或任何其他时间段）的最小值/最大值/平均值。

编辑：DBA 的主要论点是将行数减少 x500 次将允许更高效的索引和内存（在此优化之前，该表将包含数亿行）。然后在选择多个度量标准时，建议的架构将允许一个通过数据而不是每个度量的单独索引搜索。

编辑：500 个指标是一个“上限”，但实际上大部分时间每 5 秒只报告约 40 个指标（虽然不是相同的 40）

编写包含数据库的集成测试是一个常见问题。如果测试更改了数据库，那么它可能会影响其他测试或下一次运行。

我知道我可以将我的测试包装在一个事务中并在测试运行后回滚该事务。但是如果 PostgreSQL 能够提供某种全局快照或一次性覆盖，那就太好了。在理想情况下，这样的功能将涵盖数据库的所有状态，包括模式和存储过程。

我正在尝试从 Postgres 9.2 表中返回纯 JSON。

  SELECT ARRAY_TO_JSON(ARRAY_AGG(ALBUM_ROW))
  FROM (
    SELECT
      album,
      max(release_year) AS release_year,
      max(artwork_path) AS artwork_path,
      MD5(concat(album,release_year,artist)) AS token,
      ARRAY_AGG((media_files.position, media_files.token, media_files.title) ORDER BY media_files.position) as media_files
    FROM media_files
    INNER JOIN playlist_media_files ON playlist_media_files.media_file_id = media_files.id
    WHERE playlist_media_files.playlist_id = 1
    GROUP BY album, release_year, artist
    ORDER BY artist, release_year
  ) as ALBUM_ROW

这个查询工作得很好，但是就行了：

ARRAY_AGG((media_files.position, media_files.token) ORDER ...) as media_files

我想在结果集中别名position和token属性。

AS 显然这里是不允许的。

我会写：

ARRAY_AGG((media_files.position AS xxx, media_files.token AS yyy) ORDER BY media_files.position) as media_files

但它不起作用。 …

我在两台不同的机器上有两个 PostgreSQL 数据库，网络连接很慢。
我想将几个选定的行从第一个实例复制到第二个实例。不幸的是，单表的full dump太大了。CLI 解决方案就可以了。

我有一个可以包含相当大的BYTEA值的表（同样适用于大TEXT值）。它看起来像这样：

CREATE TABLE testtable (
    id SERIAL PRIMARY KEY,
    name TEXT UNIQUE NOT NULL, -- This is just an example: this could be the PK
    value BYTEA -- This could be TEXT
);

如果使用此表的应用程序尝试使用相同的 插入两行name，我会在日志中收到此错误（当然，这是预期错误）：

CREATE TABLE testtable (
    id SERIAL PRIMARY KEY,
    name TEXT UNIQUE NOT NULL, -- This is just an example: this could be the PK
    value BYTEA -- This could be TEXT
);

虽然记录错误以及记录语句（在此特定上下文中可能还有“name”的值）很有用，但记录 longBYTEA或TEXTvalue 不是。事实上，日志中的二进制数据以文本形式（例如 …

我在 PostgreSQL 中有一个长期运行的 PL/pgSQL 存储过程。如何确定其中当前正在执行的语句？

Postgres 可以在文本搜索中使用 Ispell 兼容的字典，但不提供所需的文件。

Postgre JSON 类型针对大型 JSON 文档的优化情况如何？在 JSON 对象大小为多 MB 且太大而无法有效加载的情况下，我特别关注部分检索（例如获取 JSON 数组的最后 N 个项目或在 JSON dict 中查找一个特定项目的成本）在全。

背景：我正在处理一个数据集，其中每条记录都有 10,000 条注释。我不需要这些注释完全索引，但我需要快速插入记录，所以我考虑将它们存储在 JSON 字段中，而不是在映射表中创建数千个额外的行。

这与 PostgreSQL 9.3 有关。

我有一个单表的 47 GB MySQL 转储：

http://dumps.wikimedia.org/commonswiki/latest/commonswiki-latest-image.sql.gz

我最终希望它进入 PostgreSQL，但由于我没有找到一种简单的方法将 MySQL SQL 转换为我想的 PostgreSQL SQL，我将它放入 MySQL，然后编写一个小的 ETL 脚本来执行此操作。

我最初尝试使用 MySQL WorkBench Data Import/Restore 加载它，但它失败了。

现在我已经运行split -l 2000 commonswiki-latest-image.sql并有 20 个文件，每个文件大约 2 GB，但它仍然失败：

23:12:28 Restoring C:\temp\commonswiki\xaa.sql

Running: mysql.exe --defaults-extra-file="c:\users\jmurdoch\appdata\local\temp\tmpi_ltz8.cnf"  --host=127.0.0.1 --user=root --port=3306 --default-character-set=utf8 --comments --database=mediawikiimages < "C:\\temp\\commonswiki\\xaa.sql"

ERROR 2013 (HY000) at line 331: Lost connection to MySQL server during query


Operation failed with exitcode 1

00:54:17 Import of C:\temp\commonswiki\xaa.sql has finished with 1 errors

它也非常慢，因为它在近 2 个小时内只导入了 209236 行，但我认为有大约 2000 万个项目要导入，所以按照这个速度导入需要 …