huge disparities in =/IN/BETWEEN performance

Поиск
Список
Период
Сортировка
От George Pavlov
Тема huge disparities in =/IN/BETWEEN performance
Дата
Msg-id 8C5B026B51B6854CBE88121DBF097A86815F42@ehost010-33.exch010.intermedia.net
обсуждение исходный текст
Ответы Re: huge disparities in =/IN/BETWEEN performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-sql
all my SQL-writin' life i have been assuming that expressions like =,
IN, BETWEEN in the WHERE clause are, in the most general sense,
alternative ways of doing the same things. i am hitting some very very
bizarre results in PGSQL:

i have a (very involved) view, say v_foo, largely optimized to be
queried by a user_id column, so:
 select * from v_foo where user_id = 70728; Time: 580.620 ms

however an essentially synonymous IN construct takes minutes to complete
(the subquery inside the IN clause will return the 70728 ID and by
itself takes 40ms to complete):
 select * from v_foo where user_id in (select user_id from bar group by
1 having count(*) = 10 limit 1); Time: 244616.464 ms

a synonymous-looking BETWEEN also takes forever:
 select * from v_foo where user_id between 70728 and 70728; Time: 329332.722 ms

there is, admittedly, substantial complexity inside v_foo, with GROUP
BYs on user_id and various subqueries, but my basic thought is that
should not really matter...

i am on 8.1.3. i'd like to hope that the 8.2 optimizer improvements
might help with this but i haven't tested.

george


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

Предыдущее
От: "Jan Muszynski"
Дата:
Сообщение: Re: metaphone and nysiis in postgres
Следующее
От: John DeSoi
Дата:
Сообщение: Re: Seeking quick way to clone a row, but give it a new pk.