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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #3657: Performance leaks when using between of two equal dates
Следующее
От: Tiago Daniel Jacobs
Дата:
Сообщение: Re: BUG #3657: Performance leaks when using between of two equal dates