planner's midjudge number of rows resulting, despite pretty obvious join

Поиск
Список
Период
Сортировка
От Grzegorz Jaśkiewicz
Тема planner's midjudge number of rows resulting, despite pretty obvious join
Дата
Msg-id 2f4958ff0902240633y46e9ed96s3bc73434f75d269f@mail.gmail.com
обсуждение исходный текст
Ответы Re: planner's midjudge number of rows resulting, despite pretty obvious join  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-performance
explain select ss, ARRAY(select id from foo where ss>0 and id between
7 and 156 order by random() limit 3) as v from
generate_series(1,1000000) ss;
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Function Scan on generate_series ss  (cost=0.00..9381.22 rows=1000 width=4)
   SubPlan
     ->  Limit  (cost=9.36..9.37 rows=3 width=8)
           ->  Sort  (cost=9.36..9.74 rows=150 width=8)
                 Sort Key: (random())
                 ->  Result  (cost=0.00..7.42 rows=150 width=8)
                       One-Time Filter: ($0 > 0)
                       ->  Seq Scan on foo  (cost=0.00..7.05 rows=150 width=8)
                             Filter: ((id >= 7) AND (id <= 156))
(9 rows)

:(

no matter if I change last generate_series's range, it will always
estimate 1000 rows...


--
GJ

В списке pgsql-performance по дате отправления:

Предыдущее
От: Claus Guttesen
Дата:
Сообщение: Re: Abnormal performance difference between Postgres and MySQL
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: planner's midjudge number of rows resulting, despite pretty obvious join