标签: postgresql-10

ICU 指定不同的LDML 整理设置。其中一些看起来很有趣，尤其是关于大小写和口音的那些，

• “忽略重音”： strength=primary
• “忽略重音”但要考虑大小写： strength=primary caseLevel=on
• “忽略大小写”： strength=secondary
• “忽略标点符号”（完全）： strength=tertiary alternate=shifted
• “忽略标点符号”但区分标点符号：strength=quaternary alternate=shifted可能是更好的做事方法

您还可以在此处查看这些文档。PostgreSQL 10 ICU 整理支持是否可以使用这些 ICU 选项和设置？

CREATE COLLATION special (provider = icu, locale = 'en@strength=primary');
SELECT 'Å' LIKE 'A' COLLATE "special"; # returns false

我也试过CLDR BCP47

从 ICU 54 开始，排序规则属性也可以通过语言环境关键字指定，使用旧的语言环境扩展语法 (" el@colCaseFirst=upper") 或语言标记语法 ("el-u-kf-upper")。关键字和值不区分大小写。请参阅LDML 归类规范、归类设置和列出有效归类关键字及其值的数据文件。（不支持已弃用的属性 kh/colHiraganaQuaternary 和 vt/variableTop。）

为此，这看起来是对的

CREATE COLLATION special (provider = icu, locale = 'en-ks-level1');
SELECT …

我有一个具有以下结构的 PostgreSQL 表：

我只需要将TYPE的prove_identity_idfrom更改bigint为bigserial。我阅读了文档，但无法理解如何在没有以下错误的情况下合法地实现更改：PostgreSQL said: type "bigserial" does not exist

PostgreSQL 10.1 on x86_64-apple-darwin14.5.0, compiled by Apple LLVM version 7.0.0 (clang-700.1.76), 64-bit

我有一个用于存储事件的表，该表timestamptz使用按月按列分区PARTITION BY RANGE。

目前有 5 个分区，每个分区包含一个月的跨度，从 开始FOR VALUES FROM ('2018-01-01') TO ('2018-02-01')到结束FOR VALUES FROM ('2018-05-01') TO ('2018-06-01')。

大多数数据都是以线性且可预测的方式输入的。但是，事件由报告事件的应用程序消耗，并且我确实必须允许随时输入过去的事件 - 其时间戳可能早于2018-01-01，甚至是未来的事件（例如预计的费用）发生在未来的某个时间）。

我计划为过去的事件创建一个分区，这些事件的跨度将超过一个月，因为预计不会有太多此类事件。

我不确定对于尚未存在分区的未来事件的最佳方法是什么。

有没有办法获取我可以在现有分区中存储的最小/最大值？如果没有，我可以创建一个参考表来存储这些值，但我宁愿不必维护它。

我应该创建一个触发器来检查插入的每一行（看起来很昂贵）吗？我应该捕获插入错误并一次处理这些错误吗？

运行于PostgreSQL 10.3.

我使用 pg_restore 从目录备份恢复 50 GB 数据库，使用以下命令，该命令使用了 4 个作业：

pg_restore -d analytics -U postgres  -j 4 -v "D:\Program Files\PostgreSQL\10\backups\Analytics_08_2018__7_53_21.36.compressed"

我从命令行运行了这个。恢复时间比非并行恢复长约 2 小时。它似乎在恢复作业结束时继续创建索引

pg_restore: launching item 2817 INDEX nidx_bigrams_inc_hits
pg_restore: creating INDEX "public.nidx_bigrams_inc_hits"
pg_restore: finished item 2965 TABLE DATA trigrams
pg_restore: launching item 2822 INDEX nidx_trigrams_inc_hits
pg_restore: creating INDEX "public.nidx_trigrams_inc_hits"
pg_restore: finished item 2823 INDEX nidx_unigrams_inc_hits
pg_restore: finished item 2822 INDEX nidx_trigrams_inc_hits
pg_restore: finished item 2817 INDEX nidx_bigrams_inc_hits
pg_restore: finished main parallel loop

每个 pg_restore“创建索引”作业在 pg_stat_activity 中的状态均为“空闲”。另一个 pg_restore 作业在提交时“空闲”。

我希望并行恢复能够比默认恢复快得多，而且它似乎一直在这样做，直到大约 …

在放弃 MySQL 之后，我尝试了 Elasticsearch，现在不想看看我是否可以使用 PostgreSQL/PostGIS，因为它可以让我只使用 PostgreSQL。

我需要按距离（不能完全相同）从表中获取记录并按距离排序。该表有 1000 万条记录。

当我在 PostgreSQL 上查询比在 MySQL 上的查询速度慢时，我想我一定做错了什么。

我可以做什么更好？

桌子：

id | hash_id | town | geo_pt2 

geo_pt2 is geography

指数：

CREATE INDEX geo_pt2_gix ON public.member_profile USING gist (geo_pt2)

询问：

SELECT hash_id, town
     , ST_Distance(t.x, geo_pt2) AS dist
FROM   member_profile, (SELECT ST_GeographyFromText('POINT(47.4667 8.3167)')) AS t(x)
WHERE  ST_DWithin(t.x, geo_pt2, 250000)
ORDER  BY dist
limit 100 offset 1000;

解释：

Limit  (cost=9.08..9.08 rows=1 width=53)
  ->  Sort  (cost=9.07..9.08 rows=1 width=53)
        Sort Key: (_st_distance('0101000020E610000088855AD3BCBB474052499D8026A22040'::geography, member_profile.geo_pt2, '0'::double precision, true))
        -> …

Postgres 版本

使用 PostgreSQL 10.3。

表定义

CREATE TABLE tickets (
  id bigserial primary key,
  state character varying,
  closed timestamp
);

CREATE INDEX  "state_index" ON "tickets" ("state")
  WHERE ((state)::text = 'open'::text));

基数

该表包含 1027616 行，其中 51533 行具有state = 'open'和closed IS NULL或 5%。

条件为 on 的查询state按预期使用索引扫描执行良好：

explain analyze select * from tickets where state = 'open';

Index Scan using state_index on tickets  (cost=0.29..16093.57 rows=36599 width=212) (actual time=0.025..22.875 rows=37346 loops=1)
Planning time: 0.212 ms
Execution time: 25.697 …

我在 /usr/bin 下找不到 pg_resetxlog。

postgres (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)

cd /usr/bin
postgres@node-1:/usr/bin$ ./pg_resetxlog
-su: ./pg_resetxlog: No such file or directory

太长了；博士

以下查询在执行时会阻止 postgres 服务器

ALTER TABLE "image_data" ADD COLUMN "user_status" varchar(30) NULL

引擎版本10.6

行数 1.5 mil

你好，

我的生产数据库服务器有一个有点奇怪的问题（我无法在本地服务器上重现）。作为部署过程的一部分，我想添加一个默认值为null的新列。当我运行上述查询（由 dajngo 的迁移过程生成）时，它失败了，并且在此过程中锁定了数据库并阻止了其他查询（非锁定选择）的执行。由于是生产环境，所以几分钟后（大约10分钟）就回滚了。我发现最不寻常的是，相同的查询在我的本地数据库复制（具有与生产完全相同的数据）上执行不到一秒。

编辑：当我运行此事务时，它会阻止所有其他选择查询对数据库的访问 - 我认为（如果我错了，请纠正我）意味着数据库实际上被此事务阻止了。

我有一个Shipment表，其中包含有关货件的一些基本数据，还有一个ShipmentItem表，其中包含有关该货件的附加属性以及foreignKey表Shipment的主键。到Shipment表ShipmentItem是OneToMany关系。

我们需要包含一个文本搜索选项，该选项采用给定的输入文本字符串，Shipment除了三个特定types的ShipmentItem名称列之外，还搜索 (make) 的超过 2 个列。这是我当前的查询：

select *
from Shipment shipment
where shipment.deliveryRequestedDate >= '2019-06-09T00:00:00Z'
  and shipment.deliveryRequestedDate <= '2019-12-06T23:59:59Z'
  and (
        shipment.identifierkeyvalues = '12345'
        or shipment.carrierReferenceNumber = '12345'
        or shipment.uuid in (
            select shipmentItem.resultId
            from ShipmentItem shipmentItem
            where (
                shipmentItem.type in (
                                      'poNumber', 'deliveryNoteNumber', 'salesOrderNumber'
                )
            )
            and shipmentItem.name = '12345'
            and shipmentItem.deliveryRequestedDate >= '2019-06-09T00:00:00Z'
            and shipmentItem.deliveryRequestedDate <= '2019-12-06T23:59:59Z'
       ) …

我正在使用AWS Aurora PostgreSQL Serverless自动缩放。看起来好像缩放清除了共享缓冲区，所以当我们想要提高性能时，我们被迫面对 I/O 瓶颈。在我们热身之后，我们看到了巨大的性能提升。但是，如果我们在缩放后背靠背运行，则第二次运行会更快。虽然我没有看到任何关于共享缓冲区是否在缩放时被清除的具体信息，但我几乎肯定它是。

Aurora Serverless 目前正在使用PostgreSQL 10.14，并且支持pg_prewarm扩展。它看起来像最新的文件显示在服务器重新启动后prewarm支持自动prewarm，但这是无服务器并不会出现提自动预暖的一个版本的文档中。

我发现这篇文章在重新启动服务器或从崩溃中恢复时非常适合 PostgreSQL。

1. 如果我们至少可以在缩放后保留下 ACU 节点的共享缓冲区的内容，那就没问题了。
2. 如果我们可以提前预热需要在内存中的内容，那就太棒了！
3. 有些桌子非常大，我们希望有选择地预热我们想要的作品。 pg_prewarm支持first_block和last_block阻止表/索引的编号，但是如何知道要放入哪些值呢？

我们提前知道我们的峰值是什么时候，并告诉 RDS 在此之前进行扩展，因此我们有一个可以准备的时间窗口。

我有哪些选择？