migrate-postgres-tables-to-hypertables

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PostgreSQL to TimescaleDB Hypertable Migration

PostgreSQL 转 TimescaleDB Hypertable 迁移

Migrate identified PostgreSQL tables to TimescaleDB hypertables with optimal configuration, migration planning and validation.
Prerequisites: Tables already identified as hypertable candidates (use companion "find-hypertable-candidates" skill if needed).
将已选定的PostgreSQL表迁移至TimescaleDB hypertables,同时完成最优配置、迁移规划与验证。
前提条件:已确定为hypertable候选表(如有需要,可搭配使用"find-hypertable-candidates"技能)。

Step 1: Optimal Configuration

步骤1:最优配置

Partition Column Selection

分区列选择

sql
-- Find potential partition columns
SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_name = 'your_table_name'
  AND data_type IN ('timestamp', 'timestamptz', 'bigint', 'integer', 'date')
ORDER BY ordinal_position;
Requirements: Time-based (TIMESTAMP/TIMESTAMPTZ/DATE) or sequential integer (INT/BIGINT)
Should represent when the event actually occurred or sequential ordering.
Common choices:
  • timestamp
    ,
    created_at
    ,
    event_time
    - when event occurred
  • id
    ,
    sequence_number
    - auto-increment (for sequential data without timestamps)
  • ingested_at
    - less ideal, only if primary query dimension
  • updated_at
    - AVOID (records updated out of order, breaks chunk distribution) unless primary query dimension
sql
-- Find potential partition columns
SELECT column_name, data_type, is_nullable
FROM information_schema.columns
WHERE table_name = 'your_table_name'
  AND data_type IN ('timestamp', 'timestamptz', 'bigint', 'integer', 'date')
ORDER BY ordinal_position;
要求: 基于时间(TIMESTAMP/TIMESTAMPTZ/DATE)或连续整数(INT/BIGINT)类型
需代表事件实际发生时间或连续排序逻辑。
常见选择:
  • timestamp
    created_at
    event_time
    - 事件发生时间
  • id
    sequence_number
    - 自增字段(适用于无时间戳的连续数据)
  • ingested_at
    - 较不理想,仅当为主要查询维度时使用
  • updated_at
    - 避免使用(记录更新顺序混乱,会破坏块分布),除非是主要查询维度

Special Case: table with BOTH ID AND Timestamp

特殊场景:同时包含ID与时间戳的表

When table has sequential ID (PK) AND timestamp that correlate:
sql
-- Partition by ID, enable minmax sparse indexes on timestamp
SELECT create_hypertable('orders', 'id', chunk_time_interval => 1000000);
ALTER TABLE orders SET (
    timescaledb.sparse_index = 'minmax(created_at),...'
);
Sparse indexes on time column enable skipping compressed blocks outside queried time ranges.
Use when: ID correlates with time (newer records have higher IDs), need ID-based lookups, time queries also common
当表中存在连续ID(主键)且与时间戳相关联时:
sql
-- Partition by ID, enable minmax sparse indexes on timestamp
SELECT create_hypertable('orders', 'id', chunk_time_interval => 1000000);
ALTER TABLE orders SET (
    timescaledb.sparse_index = 'minmax(created_at),...'
);
在时间列上创建稀疏索引可跳过查询时间范围外的压缩块。
适用场景:ID与时间相关联(新记录ID更大)、需要基于ID查询、同时频繁进行时间维度查询

Chunk Interval Selection

块间隔选择

sql
-- Ensure statistics are current
ANALYZE your_table_name;

-- Estimate index size per time unit
WITH time_range AS (
    SELECT
        MIN(timestamp_column) as min_time,
        MAX(timestamp_column) as max_time,
        EXTRACT(EPOCH FROM (MAX(timestamp_column) - MIN(timestamp_column)))/3600 as total_hours
    FROM your_table_name
),
total_index_size AS (
    SELECT SUM(pg_relation_size(indexname::regclass)) as total_index_bytes
    FROM pg_stat_user_indexes
    WHERE schemaname||'.'||tablename = 'your_schema.your_table_name'
)
SELECT
    pg_size_pretty(tis.total_index_bytes / tr.total_hours) as index_size_per_hour
FROM time_range tr, total_index_size tis;
Target: Indexes of recent chunks < 25% of RAM Default: IMPORTANT: Keep default of 7 days if unsure Range: 1 hour minimum, 30 days maximum
Example: 32GB RAM → target 8GB for recent indexes. If index_size_per_hour = 200MB:
  • 1 hour chunks: 200MB chunk index size × 40 recent = 8GB ✓
  • 6 hour chunks: 1.2GB chunk index size × 7 recent = 8.4GB ✓
  • 1 day chunks: 4.8GB chunk index size × 2 recent = 9.6GB ⚠️ Choose largest interval keeping 2+ recent chunk indexes under target.
sql
-- Ensure statistics are current
ANALYZE your_table_name;

-- Estimate index size per time unit
WITH time_range AS (
    SELECT
        MIN(timestamp_column) as min_time,
        MAX(timestamp_column) as max_time,
        EXTRACT(EPOCH FROM (MAX(timestamp_column) - MIN(timestamp_column)))/3600 as total_hours
    FROM your_table_name
),
total_index_size AS (
    SELECT SUM(pg_relation_size(indexname::regclass)) as total_index_bytes
    FROM pg_stat_user_indexes
    WHERE schemaname||'.'||tablename = 'your_schema.your_table_name'
)
SELECT
    pg_size_pretty(tis.total_index_bytes / tr.total_hours) as index_size_per_hour
FROM time_range tr, total_index_size tis;
目标: 近期块的索引大小小于内存的25% 默认值: 重要提示:若不确定,保留默认7天 范围: 最小1小时,最大30天
示例: 32GB内存 → 目标近期索引大小为8GB。若每小时索引大小=200MB:
  • 1小时块:200MB块索引大小 × 40个近期块 = 8GB ✓
  • 6小时块:1.2GB块索引大小 ×7个近期块=8.4GB ✓
  • 1天块:4.8GB块索引大小 ×2个近期块=9.6GB ⚠️ 选择最大的间隔,确保2个以上近期块的索引大小在目标范围内。

Primary Key/ Unique Constraints Compatibility

主键/唯一约束兼容性

sql
-- Check existing primary key/ unique constraints
SELECT conname, pg_get_constraintdef(oid) as definition
FROM pg_constraint
WHERE conrelid = 'your_table_name'::regclass AND contype = 'p' OR contype = 'u';
Rules: PK/UNIQUE must include partition column
Actions:
  1. No PK/UNIQUE: No changes needed
  2. PK/UNIQUE includes partition column: No changes needed
  3. PK/UNIQUE excludes partition column: ⚠️ ASK USER PERMISSION to modify PK/UNIQUE
Example: user prompt if needed:
"Primary key (id) doesn't include partition column (timestamp). Must modify to PRIMARY KEY (id, timestamp) to convert to hypertable. This may break application code. Is this acceptable?" "Unique constraint (id) doesn't include partition column (timestamp). Must modify to UNIQUE (id, timestamp) to convert to hypertable. This may break application code. Is this acceptable?"
If the user accepts, modify the constraint:
sql
BEGIN;
ALTER TABLE your_table_name DROP CONSTRAINT existing_pk_name;
ALTER TABLE your_table_name ADD PRIMARY KEY (existing_columns, partition_column);
COMMIT;
If the user does not accept, you should NOT migrate the table.
IMPORTANT: DO NOT modify the primary key/unique constraint without user permission.
sql
-- Check existing primary key/ unique constraints
SELECT conname, pg_get_constraintdef(oid) as definition
FROM pg_constraint
WHERE conrelid = 'your_table_name'::regclass AND contype = 'p' OR contype = 'u';
规则: 主键/唯一约束必须包含分区列
操作:
  1. 无主键/唯一约束: 无需修改
  2. 主键/唯一约束包含分区列: 无需修改
  3. 主键/唯一约束不包含分区列: ⚠️ 需征得用户同意后修改主键/唯一约束
示例:必要时向用户提示:
"主键(id)未包含分区列(timestamp)。必须修改为PRIMARY KEY (id, timestamp)才能转换为hypertable。这可能会破坏应用代码。是否接受此修改?" "唯一约束(id)未包含分区列(timestamp)。必须修改为UNIQUE (id, timestamp)才能转换为hypertable。这可能会破坏应用代码。是否接受此修改?"
若用户同意,修改约束:
sql
BEGIN;
ALTER TABLE your_table_name DROP CONSTRAINT existing_pk_name;
ALTER TABLE your_table_name ADD PRIMARY KEY (existing_columns, partition_column);
COMMIT;
若用户不同意,则不应迁移该表。
重要提示:未经用户许可,不得修改主键/唯一约束。

Compression Configuration

压缩配置

For detailed segment_by and order_by selection, see "setup-timescaledb-hypertables" skill. Quick reference:
segment_by: Most common WHERE filter with >100 rows per value per chunk
  • IoT:
    device_id
  • Finance:
    symbol
  • Analytics:
    user_id
    or
    session_id
sql
-- Analyze cardinality for segment_by selection
SELECT column_name, COUNT(DISTINCT column_name) as unique_values,
       ROUND(COUNT(*)::float / COUNT(DISTINCT column_name), 2) as avg_rows_per_value
FROM your_table_name GROUP BY column_name;
order_by: Usually
timestamp DESC
. The (segment_by, order_by) combination should form a natural time-series progression.
  • If column has <100 rows/chunk (too low for segment_by), prepend to order_by:
    order_by='low_density_col, timestamp DESC'
sparse indexes: add minmax on the columns that are used in the WHERE clauses but are not in the segment_by or order_by. Use minmax for columns used in range queries.
sql
ALTER TABLE your_table_name SET (
    timescaledb.enable_columnstore,
    timescaledb.segmentby = 'entity_id',
    timescaledb.orderby = 'timestamp DESC'
    timescaledb.sparse_index = 'minmax(value_1),...'
);

-- Compress after data unlikely to change (adjust `after` parameter based on update patterns)
CALL add_columnstore_policy('your_table_name', after => INTERVAL '7 days');
关于segment_by和order_by的详细选择,请参考"setup-timescaledb-hypertables"技能。快速参考:
segment_by: 最常用的WHERE过滤字段,每个块中对应值的行数需>100
  • IoT场景:
    device_id
  • 金融场景:
    symbol
  • 分析场景:
    user_id
    session_id
sql
-- Analyze cardinality for segment_by selection
SELECT column_name, COUNT(DISTINCT column_name) as unique_values,
       ROUND(COUNT(*)::float / COUNT(DISTINCT column_name), 2) as avg_rows_per_value
FROM your_table_name GROUP BY column_name;
order_by: 通常为
timestamp DESC
。(segment_by, order_by)的组合应符合自然时间序列的进展。
  • 若字段在每个块中的行数<100(segment_by的密度过低),则将其添加至order_by开头:
    order_by='low_density_col, timestamp DESC'
稀疏索引: 为WHERE子句中使用但未包含在segment_by或order_by中的列添加minmax索引。对范围查询的列使用minmax索引。
sql
ALTER TABLE your_table_name SET (
    timescaledb.enable_columnstore,
    timescaledb.segmentby = 'entity_id',
    timescaledb.orderby = 'timestamp DESC'
    timescaledb.sparse_index = 'minmax(value_1),...'
);

-- Compress after data unlikely to change (adjust `after` parameter based on update patterns)
CALL add_columnstore_policy('your_table_name', after => INTERVAL '7 days');

Step 2: Migration Planning

步骤2:迁移规划

Pre-Migration Checklist

迁移前检查清单

  • Partition column selected
  • Chunk interval calculated (or using default)
  • PK includes partition column OR user approved modification
  • No Hypertable→Hypertable foreign keys
  • Unique constraints include partition column
  • Created compression configuration (segment_by, order_by, sparse indexes, compression policy)
  • Maintenance window scheduled / backup created.
  • 已选择分区列
  • 已计算块间隔(或使用默认值)
  • 主键包含分区列或用户已批准修改
  • 不存在Hypertable→Hypertable外键
  • 唯一约束包含分区列
  • 已创建压缩配置(segment_by、order_by、稀疏索引、压缩策略)
  • 已安排维护窗口/创建备份

Migration Options

迁移选项

Option 1: In-Place (Tables < 1GB)

选项1:原地迁移(表大小<1GB)

sql
-- Enable extension
CREATE EXTENSION IF NOT EXISTS timescaledb;

-- Convert to hypertable (locks table)
SELECT create_hypertable(
    'your_table_name',
    'timestamp_column',
    chunk_time_interval => INTERVAL '7 days',
    if_not_exists => TRUE
);

-- Configure compression
ALTER TABLE your_table_name SET (
    timescaledb.enable_columnstore,
    timescaledb.segmentby = 'entity_id',
    timescaledb.orderby = 'timestamp DESC',
    timescaledb.sparse_index = 'minmax(value_1),...'
);

-- Adjust `after` parameter based on update patterns
CALL add_columnstore_policy('your_table_name', after => INTERVAL '7 days');
sql
-- Enable extension
CREATE EXTENSION IF NOT EXISTS timescaledb;

-- Convert to hypertable (locks table)
SELECT create_hypertable(
    'your_table_name',
    'timestamp_column',
    chunk_time_interval => INTERVAL '7 days',
    if_not_exists => TRUE
);

-- Configure compression
ALTER TABLE your_table_name SET (
    timescaledb.enable_columnstore,
    timescaledb.segmentby = 'entity_id',
    timescaledb.orderby = 'timestamp DESC',
    timescaledb.sparse_index = 'minmax(value_1),...'
);

-- Adjust `after` parameter based on update patterns
CALL add_columnstore_policy('your_table_name', after => INTERVAL '7 days');

Option 2: Blue-Green (Tables > 1GB)

选项2:蓝绿迁移(表大小>1GB)

sql
-- 1. Create new hypertable
CREATE TABLE your_table_name_new (LIKE your_table_name INCLUDING ALL);

-- 2. Convert to hypertable
SELECT create_hypertable('your_table_name_new', 'timestamp_column');

-- 3. Configure compression
ALTER TABLE your_table_name_new SET (
    timescaledb.enable_columnstore,
    timescaledb.segmentby = 'entity_id',
    timescaledb.orderby = 'timestamp DESC'
);

-- 4. Migrate data in batches
INSERT INTO your_table_name_new
SELECT * FROM your_table_name
WHERE timestamp_column >= '2024-01-01' AND timestamp_column < '2024-02-01';
-- Repeat for each time range

-- 4. Enter maintenance window and do the following:

-- 5. Pause modification of the old table.

-- 6. Copy over the most recent data from the old table to the new table.

-- 7. Swap tables
BEGIN;
ALTER TABLE your_table_name RENAME TO your_table_name_old;
ALTER TABLE your_table_name_new RENAME TO your_table_name;
COMMIT;

-- 8. Exit maintenance window.

-- 9. (sometime much later) Drop old table after validation
-- DROP TABLE your_table_name_old;
sql
-- 1. Create new hypertable
CREATE TABLE your_table_name_new (LIKE your_table_name INCLUDING ALL);

-- 2. Convert to hypertable
SELECT create_hypertable('your_table_name_new', 'timestamp_column');

-- 3. Configure compression
ALTER TABLE your_table_name_new SET (
    timescaledb.enable_columnstore,
    timescaledb.segmentby = 'entity_id',
    timescaledb.orderby = 'timestamp DESC'
);

-- 4. Migrate data in batches
INSERT INTO your_table_name_new
SELECT * FROM your_table_name
WHERE timestamp_column >= '2024-01-01' AND timestamp_column < '2024-02-01';
-- Repeat for each time range

-- 4. Enter maintenance window and do the following:

-- 5. Pause modification of the old table.

-- 6. Copy over the most recent data from the old table to the new table.

-- 7. Swap tables
BEGIN;
ALTER TABLE your_table_name RENAME TO your_table_name_old;
ALTER TABLE your_table_name_new RENAME TO your_table_name;
COMMIT;

-- 8. Exit maintenance window.

-- 9. (sometime much later) Drop old table after validation
-- DROP TABLE your_table_name_old;

Common Issues

常见问题

Foreign Keys

外键

sql
-- Check foreign keys
SELECT conname, confrelid::regclass as referenced_table
FROM pg_constraint
WHERE (conrelid = 'your_table_name'::regclass
    OR confrelid = 'your_table_name'::regclass)
  AND contype = 'f';
Supported: Plain→Hypertable, Hypertable→Plain NOT supported: Hypertable→Hypertable
⚠️ CRITICAL: Hypertable→Hypertable FKs must be dropped (enforce in application). ASK USER PERMISSION. If no, STOP MIGRATION.
sql
-- Check foreign keys
SELECT conname, confrelid::regclass as referenced_table
FROM pg_constraint
WHERE (conrelid = 'your_table_name'::regclass
    OR confrelid = 'your_table_name'::regclass)
  AND contype = 'f';
支持: 普通表→Hypertable、Hypertable→普通表 不支持: Hypertable→Hypertable
⚠️ 关键提示: Hypertable→Hypertable外键必须删除(在应用层实现约束)。需征得用户许可。若用户不同意,终止迁移

Large Table Migration Time

大表迁移时间

sql
-- Rough estimate: ~75k rows/second
SELECT
    pg_size_pretty(pg_total_relation_size(tablename)) as size,
    n_live_tup as rows,
    ROUND(n_live_tup / 75000.0 / 60, 1) as estimated_minutes
FROM pg_stat_user_tables
WHERE tablename = 'your_table_name';
Solutions for large tables (>1GB/10M rows): Use blue-green migration, migrate during off-peak, test on subset first
sql
-- Rough estimate: ~75k rows/second
SELECT
    pg_size_pretty(pg_total_relation_size(tablename)) as size,
    n_live_tup as rows,
    ROUND(n_live_tup / 75000.0 / 60, 1) as estimated_minutes
FROM pg_stat_user_tables
WHERE tablename = 'your_table_name';
大表解决方案(>1GB/1000万行): 使用蓝绿迁移、在非高峰时段迁移、先在子集上测试

Step 3: Performance Validation

步骤3:性能验证

Chunk & Compression Analysis

块与压缩分析

sql
-- View chunks and compression
SELECT
    chunk_name,
    pg_size_pretty(total_bytes) as size,
    pg_size_pretty(compressed_total_bytes) as compressed_size,
    ROUND((total_bytes - compressed_total_bytes::numeric) / total_bytes * 100, 1) as compression_pct,
    range_start,
    range_end
FROM timescaledb_information.chunks
WHERE hypertable_name = 'your_table_name'
ORDER BY range_start DESC;
Look for:
  • Consistent chunk sizes (within 2x)
  • Compression >90% for time-series
  • Recent chunks uncompressed
  • Chunk indexes < 25% RAM
sql
-- View chunks and compression
SELECT
    chunk_name,
    pg_size_pretty(total_bytes) as size,
    pg_size_pretty(compressed_total_bytes) as compressed_size,
    ROUND((total_bytes - compressed_total_bytes::numeric) / total_bytes * 100, 1) as compression_pct,
    range_start,
    range_end
FROM timescaledb_information.chunks
WHERE hypertable_name = 'your_table_name'
ORDER BY range_start DESC;
检查要点:
  • 块大小一致(在2倍范围内)
  • 时间序列数据的压缩率>90%
  • 近期块未压缩
  • 块索引大小<内存的25%

Query Performance Tests

查询性能测试

sql
-- 1. Time-range query (should show chunk exclusion)
EXPLAIN (ANALYZE, BUFFERS)
SELECT COUNT(*), AVG(value)
FROM your_table_name
WHERE timestamp >= NOW() - INTERVAL '1 day';

-- 2. Entity + time query (benefits from segment_by)
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM your_table_name
WHERE entity_id = 'X' AND timestamp >= NOW() - INTERVAL '1 week';

-- 3. Aggregation (benefits from columnstore)
EXPLAIN (ANALYZE, BUFFERS)
SELECT DATE_TRUNC('hour', timestamp), entity_id, COUNT(*), AVG(value)
FROM your_table_name
WHERE timestamp >= NOW() - INTERVAL '1 month'
GROUP BY 1, 2;
✅ Good signs:
  • "Chunks excluded during startup: X" in EXPLAIN plan
  • "Custom Scan (ColumnarScan)" for compressed data
  • Lower "Buffers: shared read" in EXPLAIN ANALYZE plan than pre-migration
  • Faster execution times
❌ Bad signs:
  • "Seq Scan" on large chunks
  • No chunk exclusion messages
  • Slower than before migration
sql
-- 1. Time-range query (should show chunk exclusion)
EXPLAIN (ANALYZE, BUFFERS)
SELECT COUNT(*), AVG(value)
FROM your_table_name
WHERE timestamp >= NOW() - INTERVAL '1 day';

-- 2. Entity + time query (benefits from segment_by)
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM your_table_name
WHERE entity_id = 'X' AND timestamp >= NOW() - INTERVAL '1 week';

-- 3. Aggregation (benefits from columnstore)
EXPLAIN (ANALYZE, BUFFERS)
SELECT DATE_TRUNC('hour', timestamp), entity_id, COUNT(*), AVG(value)
FROM your_table_name
WHERE timestamp >= NOW() - INTERVAL '1 month'
GROUP BY 1, 2;
✅ 良好迹象:
  • 执行计划中显示"Chunks excluded during startup: X"
  • 压缩数据使用"Custom Scan (ColumnarScan)"
  • 执行计划中"Buffers: shared read"数值比迁移前更低
  • 执行时间更快
❌ 不良迹象:
  • 对大块执行"Seq Scan"
  • 无块排除信息
  • 性能比迁移前更慢

Storage Metrics

存储指标

sql
-- Monitor compression effectiveness
SELECT
    hypertable_name,
    pg_size_pretty(total_bytes) as total_size,
    pg_size_pretty(compressed_total_bytes) as compressed_size,
    ROUND(compressed_total_bytes::numeric / total_bytes * 100, 1) as compressed_pct_of_total,
    ROUND((uncompressed_total_bytes - compressed_total_bytes::numeric) /
          uncompressed_total_bytes * 100, 1) as compression_ratio_pct
FROM timescaledb_information.hypertables
WHERE hypertable_name = 'your_table_name';
Monitor:
  • compression_ratio_pct >90% (typical time-series)
  • compressed_pct_of_total growing as data ages
  • Size growth slowing significantly vs pre-hypertable
  • Decreasing compression_ratio_pct = poor segment_by
sql
-- Monitor compression effectiveness
SELECT
    hypertable_name,
    pg_size_pretty(total_bytes) as total_size,
    pg_size_pretty(compressed_total_bytes) as compressed_size,
    ROUND(compressed_total_bytes::numeric / total_bytes * 100, 1) as compressed_pct_of_total,
    ROUND((uncompressed_total_bytes - compressed_total_bytes::numeric) /
          uncompressed_total_bytes * 100, 1) as compression_ratio_pct
FROM timescaledb_information.hypertables
WHERE hypertable_name = 'your_table_name';
监控要点:
  • 时间序列数据的compression_ratio_pct>90%
  • compressed_pct_of_total随数据老化而增长
  • 总大小增长速度比迁移前显著放缓
  • compression_ratio_pct下降=segment_by选择不当

Troubleshooting

故障排查

Poor Chunk Exclusion

块排除效果差

sql
-- Verify chunks are being excluded
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM your_table_name
WHERE timestamp >= '2024-01-01' AND timestamp < '2024-01-02';
-- Look for "Chunks excluded during startup: X"
sql
-- Verify chunks are being excluded
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM your_table_name
WHERE timestamp >= '2024-01-01' AND timestamp < '2024-01-02';
-- Look for "Chunks excluded during startup: X"

Poor Compression

压缩效果差

sql
-- Get newest compressed chunk name
SELECT chunk_name FROM timescaledb_information.chunks
WHERE hypertable_name = 'your_table_name'
  AND compressed_total_bytes IS NOT NULL
ORDER BY range_start DESC LIMIT 1;

-- Analyze segment distribution
SELECT segment_by_column, COUNT(*) as rows_per_segment
FROM _timescaledb_internal._hyper_X_Y_chunk  -- Use actual chunk name
GROUP BY 1 ORDER BY 2 DESC;
Look for: <20 rows per segment: Poor segment_by choice (should be >100) => Low compression potential.
sql
-- Get newest compressed chunk name
SELECT chunk_name FROM timescaledb_information.chunks
WHERE hypertable_name = 'your_table_name'
  AND compressed_total_bytes IS NOT NULL
ORDER BY range_start DESC LIMIT 1;

-- Analyze segment distribution
SELECT segment_by_column, COUNT(*) as rows_per_segment
FROM _timescaledb_internal._hyper_X_Y_chunk  -- Use actual chunk name
GROUP BY 1 ORDER BY 2 DESC;
检查要点: 每个segment的行数<20:segment_by选择不当(应>100)→ 压缩潜力低。

Poor insert performance

插入性能差

Check that you don't have too many indexes. Unused indexes hurt insert performance and should be dropped.
sql
SELECT
    schemaname,
    tablename,
    indexname,
    idx_tup_read,
    idx_tup_fetch,
    idx_scan
FROM pg_stat_user_indexes
WHERE tablename LIKE '%your_table_name%'
ORDER BY idx_scan DESC;
Look for: Unused indexes via a low idx_scan value. Drop such indexes (but ask user permission).
检查是否存在过多索引。未使用的索引会影响插入性能,应删除。
sql
SELECT
    schemaname,
    tablename,
    indexname,
    idx_tup_read,
    idx_tup_fetch,
    idx_scan
FROM pg_stat_user_indexes
WHERE tablename LIKE '%your_table_name%'
ORDER BY idx_scan DESC;
检查要点: idx_scan数值低的索引为未使用索引。删除此类索引(需征得用户许可)。

Ongoing Monitoring

持续监控

sql
-- Monitor chunk compression status
CREATE OR REPLACE VIEW hypertable_compression_status AS
SELECT
    h.hypertable_name,
    COUNT(c.chunk_name) as total_chunks,
    COUNT(c.chunk_name) FILTER (WHERE c.compressed_total_bytes IS NOT NULL) as compressed_chunks,
    ROUND(
        COUNT(c.chunk_name) FILTER (WHERE c.compressed_total_bytes IS NOT NULL)::numeric /
        COUNT(c.chunk_name) * 100, 1
    ) as compression_coverage_pct,
    pg_size_pretty(SUM(c.total_bytes)) as total_size,
    pg_size_pretty(SUM(c.compressed_total_bytes)) as compressed_size
FROM timescaledb_information.hypertables h
LEFT JOIN timescaledb_information.chunks c ON h.hypertable_name = c.hypertable_name
GROUP BY h.hypertable_name;

-- Query this view regularly to monitor compression progress
SELECT * FROM hypertable_compression_status
WHERE hypertable_name = 'your_table_name';
Look for:
  • compression_coverage_pct should increase over time as data ages and gets compressed.
  • total_chunks should not grow too quickly (more than 10000 becomes a problem).
  • You should not see unexpected spikes in total_size or compressed_size.
sql
-- Monitor chunk compression status
CREATE OR REPLACE VIEW hypertable_compression_status AS
SELECT
    h.hypertable_name,
    COUNT(c.chunk_name) as total_chunks,
    COUNT(c.chunk_name) FILTER (WHERE c.compressed_total_bytes IS NOT NULL) as compressed_chunks,
    ROUND(
        COUNT(c.chunk_name) FILTER (WHERE c.compressed_total_bytes IS NOT NULL)::numeric /
        COUNT(c.chunk_name) * 100, 1
    ) as compression_coverage_pct,
    pg_size_pretty(SUM(c.total_bytes)) as total_size,
    pg_size_pretty(SUM(c.compressed_total_bytes)) as compressed_size
FROM timescaledb_information.hypertables h
LEFT JOIN timescaledb_information.chunks c ON h.hypertable_name = c.hypertable_name
GROUP BY h.hypertable_name;

-- Query this view regularly to monitor compression progress
SELECT * FROM hypertable_compression_status
WHERE hypertable_name = 'your_table_name';
检查要点:
  • compression_coverage_pct应随数据老化和压缩而逐渐提升。
  • total_chunks不应增长过快(超过10000会出现问题)。
  • total_size或compressed_size不应出现意外峰值。

Success Criteria

成功标准

✅ Migration successful when:
  • All queries return correct results
  • Query performance equal or better
  • Compression >90% for older data
  • Chunk exclusion working for time queries
  • Insert performance acceptable
❌ Investigate if:
  • Query performance >20% worse
  • Compression <80%
  • No chunk exclusion
  • Insert performance degraded
  • Increased error rates
Focus on high-volume, insert-heavy workloads with time-based access patterns for best ROI.
✅ 迁移成功的标志:
  • 所有查询返回正确结果
  • 查询性能持平或更优
  • 旧数据压缩率>90%
  • 时间查询的块排除功能正常
  • 插入性能可接受
❌ 需要排查的情况:
  • 查询性能下降超过20%
  • 压缩率<80%
  • 无块排除
  • 插入性能下降
  • 错误率上升
针对高容量、插入密集型且基于时间访问的工作负载迁移,投资回报率最佳。