Re: BUG #3657: Performance leaks when using between of two equal dates
От | Tom Lane |
---|---|
Тема | Re: BUG #3657: Performance leaks when using between of two equal dates |
Дата | |
Msg-id | 24828.1191688097@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #3657: Performance leaks when using between of two equal dates (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: BUG #3657: Performance leaks when using between of two
equal dates
Re: BUG #3657: Performance leaks when using between of two equal dates |
Список | pgsql-bugs |
Alvaro Herrera <alvherre@commandprompt.com> writes: > Tiago Daniel Jacobs wrote: >> " -> Index Scan using idx_agreg_sig_2007_09__data_dt_data on >> agreg_sig_2007_09 agreg_sig (cost=0.00..8.70 rows=1 width=59) (actual >> time=7.143..4924.607 rows=178866 loops=1)" >> " Index Cond: ((data_dt_data >= '2007-09-01'::date) AND >> (data_dt_data <= '2007-09-01'::date))" > Please do ANALYZE agregados.agreg_sig and try the query again. The > indexscan is grossly misestimated. Not sure that it's ANALYZE's fault. Since we currently use the same selectivity estimators for > and >= (and likewise for < and <=), we have no hope of getting edge cases correct. Most of the time the stats are crude enough that it doesn't matter, but sometimes the edge value is common and then it does matter. I've been wondering if it would be worth the trouble to introduce scalarlesel and scalargesel estimators ... regards, tom lane
В списке pgsql-bugs по дате отправления: