使用SQL填充多年日历表：PostgreSQL脚本执行过慢求助

以下是针对小日期范围填充仍缓慢问题的核心排查点：

1. 日期生成方式低效 #

如果使用递归CTE生成日期序列，哪怕仅2天数据，若递归逻辑未优化（比如逐行生成而非批量），也可能产生不必要的开销。PostgreSQL原生的generate_series函数是生成连续日期的最优方式，比递归CTE效率高得多。

反例（低效递归）：

WITH RECURSIVE dates AS (
    SELECT '2023-02-16'::date AS dt
    UNION ALL
    SELECT dt + 1 FROM dates WHERE dt < '2023-02-17'
)
SELECT * FROM dates;

正例（高效批量生成）：

SELECT dt::date FROM generate_series('2023-02-16'::timestamp, '2023-02-17'::timestamp, '1 day'::interval) AS dt;

2. 计算字段的冗余或无优化逻辑 #

若每个字段的计算存在重复调用、依赖无索引的关联表，或使用未标记稳定性的自定义函数，会显著拖慢执行速度：

• 避免重复调用相同函数：比如多次调用extract(dow from dt)，可通过子查询或CTE预先计算一次复用。
• 关联节假日表时，确保日期字段有索引：若判断是否工作日依赖外部节假日表，未给holiday_date字段建索引会导致每次关联全表扫描。
• 自定义函数标记稳定性：比如is_workday(date)需标记为STABLE或IMMUTABLE，让PostgreSQL可以缓存结果，避免重复计算。

3. 目标表的额外开销 #

如果插入的目标表存在以下情况，即使少量数据也会变慢：

• 过多索引：插入时需维护所有索引，可先删除索引，插入完成后重建。
• 复杂触发器：比如BEFORE INSERT触发器中包含大量计算或关联操作，每条数据都会触发一次。
• 外键约束：若外键关联的表未建索引，会触发额外的全表检查。

4. 用执行计划定位瓶颈 #

执行EXPLAIN ANALYZE查看具体执行步骤，明确慢在哪个阶段：

EXPLAIN ANALYZE
-- 你的填充脚本
INSERT INTO calendar_table (...)
SELECT ... FROM generate_series(...);

通过执行计划可以看到是日期生成慢、计算字段慢，还是插入阶段的约束/触发器拖慢了速度。

内容的提问来源于stack exchange，提问作者Mohan