使用非独立索引上的递归cte计算不同的行

时间：2015-03-21 01:34:05

标签： sql postgresql count postgresql-9.3 unique-index

给出以下架构：

CREATE TABLE identifiers (
  id TEXT PRIMARY KEY
);

CREATE TABLE days (
  day DATE PRIMARY KEY
);

CREATE TABLE data (
  id TEXT REFERENCES identifiers
  , day DATE REFERENCES days
  , values NUMERIC[] 
); 
CREATE INDEX ON data (id, day);

计算两个时间戳之间所有不同日期的最佳方法是什么？我尝试了以下两种方法：

EXPLAIN ANALYZE
SELECT COUNT(DISTINCT day) 
FROM data 
WHERE day BETWEEN '2010-01-01' AND '2011-01-01';
                                                                        QUERY PLAN                                                                        
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=200331.32..200331.33 rows=1 width=4) (actual time=1647.574..1647.575 rows=1 loops=1)
   ->  Index Only Scan using data_day_sid_idx on data  (cost=0.56..196942.12 rows=1355678 width=4) (actual time=0.348..1180.566 rows=1362532 loops=1)
         Index Cond: ((day >= '2010-01-01'::date) AND (day <= '2011-01-01'::date))
         Heap Fetches: 0
 Total runtime: 1647.865 ms
(5 rows)

EXPLAIN ANALYZE
SELECT COUNT(DISTINCT day) 
FROM days
WHERE day BETWEEN '2010-01-01' AND '2011-01-01';
                                                           QUERY PLAN                                                           
--------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=18.95..18.96 rows=1 width=4) (actual time=0.481..0.481 rows=1 loops=1)
   ->  Index Only Scan using days_pkey on days  (cost=0.28..18.32 rows=252 width=4) (actual time=0.093..0.275 rows=252 loops=1)
         Index Cond: ((day >= '2010-01-01'::date) AND (day <= '2011-01-01'::date))
         Heap Fetches: 252
 Total runtime: 0.582 ms
(5 rows)

针对COUNT(DISTINCT day)的{​​{1}}运行良好，但它要求我保留辅助表（days）以保持合理的性能。在一般意义上，我想测试递归cte是否允许我实现类似的性能没有维护辅助表。我的查询看起来像这样，但还没有运行：

days

更新

感谢所有人的想法。看起来像维护基于触发器的不同日子表是最好的方式，包括存储和性能。感谢@ Erwin的更新，递归CTE重新开始运行。很有用。 

EXPLAIN ANALYZE
WITH RECURSIVE cte AS (
   (SELECT day FROM data ORDER BY 1 LIMIT 1)
   UNION ALL
   (  -- parentheses required
   SELECT d.day
   FROM   cte  c
   JOIN   data d ON d.day > c.day
   ORDER  BY 1 LIMIT 1
   )
)
SELECT day 
FROM cte
WHERE day BETWEEN '2010-01-01' AND '2011-01-01';

还讨论了WITH RECURSIVE cte AS ( ( -- parentheses required because of LIMIT SELECT day FROM data WHERE day >= '2010-01-01'::date -- exclude irrelevant rows early ORDER BY 1 LIMIT 1 ) UNION ALL SELECT (SELECT day FROM data WHERE day > c.day AND day < '2011-01-01'::date -- see comments below ORDER BY 1 LIMIT 1) FROM cte c WHERE day IS NOT NULL -- necessary because corr. subq. always returns row ) SELECT count(*) AS ct FROM cte WHERE day IS NOT NULL; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=53.35..53.36 rows=1 width=0) (actual time=18.217..18.217 rows=1 loops=1) CTE cte -> Recursive Union (cost=0.43..51.08 rows=101 width=4) (actual time=0.194..17.594 rows=253 loops=1) -> Limit (cost=0.43..0.46 rows=1 width=4) (actual time=0.191..0.192 rows=1 loops=1) -> Index Only Scan using data_day_idx on data data_1 (cost=0.43..235042.00 rows=8255861 width=4) (actual time=0.189..0.189 rows=1 loops=1) Index Cond: (day >= '2010-01-01'::date) Heap Fetches: 0 -> WorkTable Scan on cte c (cost=0.00..4.86 rows=10 width=4) (actual time=0.066..0.066 rows=1 loops=253) Filter: (day IS NOT NULL) Rows Removed by Filter: 0 SubPlan 1 -> Limit (cost=0.43..0.47 rows=1 width=4) (actual time=0.062..0.063 rows=1 loops=252) -> Index Only Scan using data_day_idx on data (cost=0.43..1625.59 rows=52458 width=4) (actual time=0.060..0.060 rows=1 loops=252) Index Cond: ((day > c.day) AND (day < '2011-01-01'::date)) Heap Fetches: 0 -> CTE Scan on cte (cost=0.00..2.02 rows=100 width=0) (actual time=0.199..18.066 rows=252 loops=1) Filter: (day IS NOT NULL) Rows Removed by Filter: 1 Total runtime: 19.355 ms (19 rows) 查询

EXISTS

3 个答案:

答案 0 :(得分：2)

几点说明：

对表day

的简单查询 
SELECT COUNT(DISTINCT day) 
FROM   days
WHERE  day BETWEEN '2010-01-01' AND '2011-01-01';

day被定义为PK，因此在这种情况下DISTINCT只是浪费。

具有相关suquery的递归CTE

如果没有day表包含唯一条目，则可以选择此选项。如果每天有多个行，那么该技术会付出代价，因此松散索引扫描的等效实际上比基表上的简单DISTINCT更快：

WITH RECURSIVE cte AS (
   (  -- parentheses required because of LIMIT
   SELECT day
   FROM   data
   WHERE  day >= '2010-01-01'::date  -- exclude irrelevant rows early
   ORDER  BY 1
   LIMIT  1
   )

   UNION ALL
   SELECT (SELECT day FROM data
           WHERE  day > c.day
           AND    day < '2011-01-01'::date  -- see comments below
           ORDER  BY 1
           LIMIT  1)
   FROM   cte c
   WHERE  day IS NOT NULL  -- necessary because corr. subq. always returns row
   )
SELECT count(*) AS ct
FROM   cte
WHERE  day IS NOT NULL;

索引

只有与data上的匹配索引相结合才有意义：

CREATE INDEX data_day_idx ON data (day);

day必须是领先的专栏。您在(id, day)上的问题中使用的索引也可以使用，但效率要低得多：

注释

  • 提前排除不相关的行要便宜得多。我将您的谓词集成到查询中。

  • 详细说明：

    手头的情况更简单 - 实际上最简单。

  • 您的原始时间范围为day BETWEEN '2010-01-01' AND '2011-01-01' - 这可能与预期无关。 BETWEEN .. AND .. 包含上限和下限，这样您就可以获得2010年的所有内容以及2011-01-01。您似乎更有可能在最后一天排除。所以使用d.day < '2011-01-01'（不是<=）。

EXISTS针对此特殊情况

由于您正在测试一系列可枚举天数（而不是具有无限可能值的范围），您可以使用EXISTS半连接测试此备选方案：

SELECT count(*) AS ct
FROM   generate_series('2010-01-01'::date, '2010-12-31'::date, '1d'::interval) d(day)
WHERE  EXISTS (SELECT 1 FROM data WHERE day = d.day::date);

同样，相同的简单索引也是必不可少的。

SQL Fiddle使用160k行的大型测试表演示两个查询。

答案 1 :(得分：1)

尝试在data(day)上创建索引，然后运行第一个查询：

SELECT COUNT(DISTINCT day) 
FROM data 
WHERE day BETWEEN '2010-01-01' AND '2011-01-01';

您可能会发现效果足以满足您的目的。

答案 2 :(得分：1)

我不确定为什么数据（日）的索引较慢，这似乎是最简单的选择。但如果这太慢了，你可以尝试创建一个物化的日常视图。基本上只是：

create materialized view days as
select day 
from data 
group by day;

我不相信postgres会自动更新物化视图，但至少您需要做的所有维护都是定期刷新它。或者可能在数据上创建一个刷新视图的触发器。请记住，刷新此视图可能需要一些时间，具体取决于数据表的大小，您可能只想按小时或夜间进行操作，如果您可以使用它。

或者，如果此表获得大量更新并且您需要始终保持不同的日期计数，则可以考虑返回到原始的单独日期表，但通过在数据上创建触发器来减少维护开销表来更新它。

相关问题
最新问题