Re: [ADMIN] OUTER JOIN IS SLOW

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [ADMIN] OUTER JOIN IS SLOW
Дата
Msg-id 23901.1166925355@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [ADMIN] OUTER JOIN IS SLOW  (Benjamin Arai <benjamin@araisoft.com>)
Ответы Re: [ADMIN] OUTER JOIN IS SLOW  (Benjamin Arai <benjamin@araisoft.com>)
Список pgsql-general
Benjamin Arai <benjamin@araisoft.com> writes:
>    ->  Index Scan using mutualfd_weekday_qbid_pkey_idx on
> mutualfd_weekday_qbid  (cost=0.00..6.01 rows=1 width=19) (actual
> time=34.579..8510.801 rows=253 loops=1)
>          Index Cond: ((pkey >= '2005-12-15'::date) AND (pkey <=
> '2006-12-15'::date))
>          Filter: (cusip = '92193920'::text)

Hm, so how many rows in mutualfd_weekday_qbid for that date?
And how many satisfy the cusip condition?  (I suppose 253,
but it looks like that must be a very small fraction of all
the rows for that date.)

The selectivity estimators are not great about dealing with
zero-width intervals like this one (in fact, if you look at the
code you'll find it doesn't even bother to distinguish '>' from '>='
... something we should probably try to improve sometime).

You'd probably have better luck if you could fold the WHERE condition
down to "pkey = '2005-12-15'".  Dunno how feasible that is for your
application.

            regards, tom lane

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: convert(... using windows_1251_to_utf8) - works on cli, but not in a c prog.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: tape backups