相关疑难解决方法(0)

我有一个应用程序可以批量加载到一个大表（1 亿行）中。我正在使用 Postgres 的COPY FROM功能从平面文件加载数据。目标表的主键为id。

为了让批量插入工作，我使用以下方法为加载文件中的每一行创建了 id：

 SELECT  nextval('apps_id_seq'::regclass)
 FROM    "apps"
 ORDER   BY "apps"."id" ASC
 LIMIT   1 

不幸的是，我没有看到这个查询花费的时间超过 150 秒。它会导致大量备份，因为其中一些文件包含数万行。

然而，当我在命令行运行它时，我得到了千分之一毫秒的返回结果。这是一个explain analyze：

                                                            QUERY PLAN                                                                
------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.57..0.64 rows=1 width=4) (actual time=0.016..0.017 rows=1 loops=1)
   ->  Index Only Scan using apps_pkey on apps  (cost=0.57..15886651.40 rows=228128608 width=4) (actual time=0.015..0.015 rows=1 loops=1)
     Heap Fetches: 0
 Total runtime: 0.030 ms

可能是什么导致了延迟？服务正在报告延迟NewRelic。

现在我serial在PostgreSQL 13中生成表主键，但是今天我发现ID跳跃并且ID空间有很大的间隙。会浪费很多ID。我阅读了文档，发现 PostgreSQL 有identity作为 SQL 标准生成的主键。我找到了在新版本的PostgreSQL中使用的建议identity，但我不知道ID是否连续。

在 PostgreSQL 13 中我应该怎么做才能获得没有间隙的主键 id？

解决方案1：我尝试更改serial为identity这样：

BEGIN;
ALTER TABLE public.article ALTER id DROP DEFAULT; -- drop default

DROP SEQUENCE public.article_id_seq;              -- drop owned sequence

ALTER TABLE public.article 
-- ALTER clientid SET DATA TYPE int,              -- not needed: already int
   ALTER id ADD GENERATED ALWAYS AS IDENTITY (RESTART 2270886);
COMMIT;

还是有差距。

解决方案 2：我尝试添加关于我的应用程序插入文章的 Redis 分发锁，如下所示：

def save_single(guid, pub_time, title, author, content, source, link):
    if content …