0

我尝试在 timescaleDb 1.0.0 中使用自适应分块。但它没有按预期工作。

  1. 我正在使用chunk_target_size => 'estimate'.
  2. 当我检查 chunk_target_size 时，它​​约为 1.2 亿——这似乎是合理的
  3. 现在我开始一个测试程序，它将循环 5k 次并在每个事务中插入 1k 行（所以总共只有 500 万行）
    • 然后当我检查块大小时，我看到大约 3.5k 块只有 152kB（第一个是 88B）！

我错过了什么？

SQL 语句

1-创建超表

SELECT create_hypertable('mytable', 'time', chunk_target_size => 'estimate';

2-检查 chunk_target_size

select table_name, chunk_target_size from _timescaledb_catalog.hypertable;

3-检查块大小

SELECT distinct total_size FROM chunk_relation_size_pretty('mytable');

附加信息

固定块大小：

当我将 chunk_target_size 设置为 100MB 时，chunk_target_size 将约为 1.04 亿。但是在插入数据后最大。chunk_relation_size 也只有 152kB

块时间间隔

当我设置 chunk_time_interval 而不是 chunk_target_size 时，我会得到更大的 chunk_relation_sizes。

更新 (2.11.2018)

我使用PGTune来改进数据库配置。以前只有 128MB -现在shared_buffers是 1280MB。
随着这个变化，chunk_target_size已经增加到大约 12 亿，但生成的块仍然只有 152kB。

4

2 回答 2

0

为了给你一个更准确的答案，我必须看到更多（也许试试我们的 Slack 以获得更多同步帮助？）。

在更新共享内存设置后，我会检查您是否重新制作了超表。在您再次运行之前，该估计仍将基于您之前的内存设置。目前尚不清楚您是否在更改共享内存后重新制作了超表。

于 2018-11-05T19:59:23.757 回答
0

here's a quote from the slack channel:

There are two chunk "fill" thresholds that need to be reached for adaptive chunking to kick in. One is associated with the size (number of bytes) and the other with the interval length. These thresholds protect against acting on chunks that are "underfilled". So, if you insert sparse data so that chunks do not exceed both thresholds, adaptive chunking will not change any intervals.

So it seems, that my use-case cannot use the estimation feature.
Also note, that the adaptive chunking feature is still in beta

UPDATE 04.2019

The adaptive chunking feature is now deprecated (in version 1.2)

于 2018-11-05T20:13:03.667 回答