Postgresql timescaledb—将4GB文件加载到超表时，共享内存不足

：） 我有GentooLinux，带有postgresql 11.4和timescaledb-1.3.2。 我执行timescaledb tune来优化我的postgresql数据库配置

我创建了一个包含30个字段的表，我们称之为foo。 我创建了另一个复制表，只是将其创建为一个超表，我们称之为h_foo

我有一个4gb的csv文件，我试图用

COPY。。。从…

命令

当我尝试将数据加载到一个常规表时，只需不到一分钟，就这样，完成了

当我尝试将其加载到超表时，过了一段时间，它抱怨共享内存不足，需要很长时间才能到达错误点

我认为使用timescaledb开箱即用（不知道高级配置）是值得的，但我不确定了

我将在下面粘贴我的postgresql配置文件，请告诉我是否有任何可以修改的内容，谁会帮助我加载该csv文件

多谢各位

shared_buffers = 8009MB                 # min 128kB
work_mem = 6835kB                               # min 64kB
maintenance_work_mem = 2047MB           # min 1MB
dynamic_shared_memory_type = posix      # the default is the first option
effective_io_concurrency = 200          # 1-1000; 0 disables prefetching
max_worker_processes = 23               # (change requires restart)
max_parallel_workers_per_gather = 6     # taken from max_parallel_workers
max_parallel_workers = 12               # maximum number of max_worker_processes that
wal_buffers = 16MB                      # min 32kB, -1 sets based on shared_buffers
max_wal_size = 8GB
min_wal_size = 4GB
checkpoint_completion_target = 0.9      # checkpoint target duration, 0.0 - 1.0
random_page_cost = 1.1                  # same scale as above
effective_cache_size = 24029MB
default_statistics_target = 500 # range 1-10000
log_timezone = 'Israel'
datestyle = 'iso, mdy'
timezone = 'Israel'
lc_messages = 'en_US.utf8'                      # locale for system error message
                                        # strings
lc_monetary = 'en_US.utf8'                      # locale for monetary formatting
lc_numeric = 'en_US.utf8'                       # locale for number formatting
lc_time = 'en_US.utf8'                          # locale for time formatting
default_text_search_config = 'pg_catalog.english'
shared_preload_libraries = 'timescaledb'
max_locks_per_transaction = 256        # min 10
plperl.on_init = 'use utf8; use re; package utf8; require "utf8_heavy.pl";'
timescaledb.max_background_workers = 8
timescaledb.last_tuned = '2019-07-14T16:06:04+03:00'
timescaledb.last_tuned_version = '0.6.0'

---

这显然不应该发生

你能更深入地描述你的CSV数据吗？您的表模式和创建超表的调用是什么样子的，数据的时间范围是什么？默认情况下，我们每周创建一个时间戳块。您是否使用

创建超链接表
更改了该设置，或者您的数据覆盖了大量时间范围

（例如，我们看到一位用户曾经意外地将数据库设置为每秒创建一个区块，然后尝试了一个试图创建一百万个区块的副本。数据库非常不高兴…
感谢您的回答。现在我只是创建了一个假数据来处理。数据的时间范围很长（可能是10-20年）。我没有在create_hypertable函数中更改任何内容，只是用它创建了一个hypertable并指定了一个特定的时间范围列。csv包含大约30个字段，大部分是stringsSo，使用20年，它将在COPY命令期间创建52*20=1040个块（表），并且需要能够锁定每个表。然而，上面的配置有max_locks_per_transaction=256。（不幸的是，如果锁用完，PostgreSQL会返回一条OOM消息；但愿它能更清楚地说明问题。）我建议要么将最大锁数增加到8192或16384之类的值，要么实际调整更多的参数。除非我对您的工作负载有更多了解，否则1000个块上的~4GB可能比建议的要小一些。哎呀，我的坏：）这些数据是1500年前的数据！我将创建一个新的假数据，它将保留几年，就是这样。是的，DB试图用一个复制命令创建78000个块。让我感觉好多了：）啊哈，非常感谢：）直到1500年前我才注意到我的大量测试数据！将其修复为几年，速度极快！