如何体现timescaledb在insert过程中比原生PG的优势？

CASE-1 减少shared_buffer 从3GB到512MB。

CASE-2， 4个索引，4并发，总共4亿行数据，监控PG实时写入速率

CASE-3 改用HDD机械硬盘测试

接上周一篇 timescaledb和PG写入性能测试 https://blog.csdn.net/jacicson1987/article/details/83064313

经过1亿数据量的测试，并没有发现timescaledb的在insert方面的优势。timescaledb官网上也只有一张图，并没有详细的测试场景介绍。

官网的说明是，数据量足够大，当PG的索引不在适合内存的时候，每次插入要更加频繁的访问磁盘获取索引，导致性能急剧下降。

尝试复现PG性能随着数据量/索引增大，性能下降的曲线。

测试环境与之前保持一致。

CASE-1 减少shared_buffer 从3GB到512MB。

1亿行数据，单线程，2个索引

总速率（行/s）	单线程
timescaledb	24066
PG	25046

减少shared_buffer没有效果，还是PG快。

CASE-2， 4个索引，4并发，总共4亿行数据，监控PG实时写入速率

PG单测	总行数	time cost	速率（行/s）
线程1	100000000	6320	15823
线程2	100000000	6300	15873
线程3	100000000	6333	15790
线程4	100000000	6342	15768
Total	400000000	6342	63072

实时监控其速度，保持稳定，从开始到结束，一致稳定在6.3W行/s 小幅波动。

表大小 86GB，索引 47GB

postgres=# select pg_size_pretty(pg_relation_size('cts1_time_idx'));
 pg_size_pretty 
----------------
 14 GB
(1 row)

postgres=# select pg_size_pretty(pg_relation_size('cts1_id_idx'));
 pg_size_pretty 
----------------
 11 GB
(1 row)

postgres=# select pg_size_pretty(pg_relation_size('cts1_col2_idx'));
 pg_size_pretty 
----------------
 11 GB
(1 row)

postgres=# select pg_size_pretty(pg_relation_size('cts1_col3_idx'));
 pg_size_pretty 
----------------
 11 GB
(1 row)
postgres=# select pg_size_pretty(pg_table_size('cts1'));
 pg_size_pretty 
----------------
 86 GB
(1 row)

早就超过内存最大值32GB。PG性能无衰减。

怀疑SSD性能太好，访问索引开销不足以使得性能下降，观察disk使用率都没超过70%。

CASE-3 改用HDD机械硬盘测试

重置PG data至机械硬盘。

改回shared_buffer = 3GB, 单线程1亿行测试，耗时7517秒。

总速率（行/s）	单线程
PG	13303

实时速率

实时速率波动很大，一千万行前也有一点衰减，但是和复现目标还是相去甚远。

综上几个场景下，PG 插入性能比较稳定，尤其是SSD的环境中，并不会有任何性能衰减现象。HDD中有一点衰减，如果在HDD的基础上再做参数调整，也许能复现那个跳水曲线。