我有一个应用程序可以批量加载到一个大表（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。
我在应用程序中的一个特别大的表上过度使用了 CITEXT 列。我想支持其中一些，因为如何触发所需索引的查找令人困惑。
我的问题是，我可以在不遇到任何重大困难的情况下做到这一点吗？如果我更改此设置，我是否需要重建这些字段上的任何索引？
朝这个方向发展会带来空间收益吗？
这些列不需要不区分大小写的查询。
我对该表进行了基于 2 列的计数，这些计数需要一个多小时。该表有 60 列。
我正在使用 Postgres 10.6。
我主要感兴趣的是，如果索引包含已从 CITEXT 更改为 VARCHAR 的列，是否需要重建索引。
我有一个快速增长的数据库。非常迅速。我的/db目录现在是 100%，并且pg_xlog.
我的背景是 Oracle 和 MySQL。我不知道这个数据库发生了什么。我知道我需要尽快聘请 Postgres DBA。
在短期内我可以做些什么来解决我的问题？我注意到删除数据并不能缓解我的空间问题。
pg_settings 的输出是：
archive_command /bin/true configuration file
archive_mode on configuration file
archive_timeout 1min configuration file
checkpoint_segments 100 configuration file
checkpoint_timeout 5min configuration file
client_encoding UTF8 session
DateStyle ISO, MDY configuration file
default_statistics_target 100 configuration file
default_text_search_config pg_catalog.english configuration file
effective_cache_size 1358MB configuration file
hot_standby on configuration file
hot_standby_feedback on configuration file
lc_messages C configuration file
lc_monetary C configuration file
lc_numeric C configuration file
lc_time C configuration file
listen_addresses …