Будет ли Postgres опускать предложение WHERE в VIEW с оконной функцией (Aggregate)? - PullRequest
Новая
       16

Будет ли Postgres опускать предложение WHERE в VIEW с оконной функцией (Aggregate)?

10 голосов
/ 23 сентября 2011

Документы для функции окна Pg говорят :

Строки, рассматриваемые оконной функцией, являются строками "виртуальной таблицы", созданной предложением FROM запроса, отфильтрованным его предложениями WHERE, GROUP BY и HAVING, если таковые имеются. Например, строка, удаленная из-за того, что она не удовлетворяет условию WHERE, не видна ни одной оконной функции. Запрос может содержать несколько оконных функций, которые по-разному разбивают данные на части с помощью различных предложений OVER, но все они действуют в одном наборе строк, определенных этой виртуальной таблицей.

Однако я этого не вижу. Мне кажется, что фильтр выбора находится очень близко к левому полю и вершине (последнее, что сделано). 

=# EXPLAIN SELECT * FROM chrome_nvd.view_options where fkey_style = 303451;
                                                      QUERY PLAN                                                      
----------------------------------------------------------------------------------------------------------------------
 Subquery Scan view_options  (cost=2098450.26..2142926.28 rows=14825 width=180)
   Filter: (view_options.fkey_style = 303451)
   ->  Sort  (cost=2098450.26..2105862.93 rows=2965068 width=189)
         Sort Key: o.sequence
         ->  WindowAgg  (cost=1446776.02..1506077.38 rows=2965068 width=189)
               ->  Sort  (cost=1446776.02..1454188.69 rows=2965068 width=189)
                     Sort Key: h.name, k.name
                     ->  WindowAgg  (cost=802514.45..854403.14 rows=2965068 width=189)
                           ->  Sort  (cost=802514.45..809927.12 rows=2965068 width=189)
                                 Sort Key: h.name
                                 ->  Hash Join  (cost=18.52..210141.57 rows=2965068 width=189)
                                       Hash Cond: (o.fkey_opt_header = h.id)
                                       ->  Hash Join  (cost=3.72..169357.09 rows=2965068 width=166)
                                             Hash Cond: (o.fkey_opt_kind = k.id)
                                             ->  Seq Scan on options o  (cost=0.00..128583.68 rows=2965068 width=156)
                                             ->  Hash  (cost=2.21..2.21 rows=121 width=18)
                                                   ->  Seq Scan on opt_kind k  (cost=0.00..2.21 rows=121 width=18)
                                       ->  Hash  (cost=8.80..8.80 rows=480 width=31)
                                             ->  Seq Scan on opt_header h  (cost=0.00..8.80 rows=480 width=31)
(19 rows)

Эти два WindowAgg по сути меняют план на что-то, что, кажется, никогда не закончится с гораздо более быстрым 

                                                                       QUERY PLAN                                                                       
--------------------------------------------------------------------------------------------------------------------------------------------------------
 Subquery Scan view_options  (cost=329.47..330.42 rows=76 width=164) (actual time=20.263..20.403 rows=42 loops=1)
   ->  Sort  (cost=329.47..329.66 rows=76 width=189) (actual time=20.258..20.300 rows=42 loops=1)
         Sort Key: o.sequence
         Sort Method:  quicksort  Memory: 35kB
         ->  Hash Join  (cost=18.52..327.10 rows=76 width=189) (actual time=19.427..19.961 rows=42 loops=1)
               Hash Cond: (o.fkey_opt_header = h.id)
               ->  Hash Join  (cost=3.72..311.25 rows=76 width=166) (actual time=17.679..18.085 rows=42 loops=1)
                     Hash Cond: (o.fkey_opt_kind = k.id)
                     ->  Index Scan using options_pkey on options o  (cost=0.00..306.48 rows=76 width=156) (actual time=17.152..17.410 rows=42 loops=1)
                           Index Cond: (fkey_style = 303451)
                     ->  Hash  (cost=2.21..2.21 rows=121 width=18) (actual time=0.432..0.432 rows=121 loops=1)
                           ->  Seq Scan on opt_kind k  (cost=0.00..2.21 rows=121 width=18) (actual time=0.042..0.196 rows=121 loops=1)
               ->  Hash  (cost=8.80..8.80 rows=480 width=31) (actual time=1.687..1.687 rows=480 loops=1)
                     ->  Seq Scan on opt_header h  (cost=0.00..8.80 rows=480 width=31) (actual time=0.030..0.748 rows=480 loops=1)
 Total runtime: 20.893 ms
(15 rows)

Что происходит и как мне это исправить? Я использую Postgresql 8.4.8. Вот что делает фактический вид: 

 SELECT o.fkey_style, h.name AS header, k.name AS kind
   , o.code, o.name AS option_name, o.description
     , count(*) OVER (PARTITION BY h.name) AS header_count
     , count(*) OVER (PARTITION BY h.name, k.name) AS header_kind_count
   FROM chrome_nvd.options o
   JOIN chrome_nvd.opt_header h ON h.id = o.fkey_opt_header
   JOIN chrome_nvd.opt_kind k ON k.id = o.fkey_opt_kind
  ORDER BY o.sequence;

1 Ответ

3 голосов
/ 24 сентября 2011

Нет, PostgreSQL будет толкать только предложение WHERE в VIEW, у которого нет Aggregate. (Оконные функции считаются агрегатами).

Я думаю, что это просто ограничение реализации

x: Интересно, что нужно сделать, чтобы подтолкнуть ГДЕ оговорка в этом случае.

планировщик должен знать, что WindowAgg сам по себе не добавляет избирательности, и поэтому безопасно нажимать ГДЕ вниз?

EvanCarroll; много очень сложной работы с планировщиком, я бы предположил

И

EvanCarroll: нет. условие фильтра в представлении применяется к выводу представления и сбрасывается только в том случае, если представление не включает агрегаты

...