Poor performance with queries using clause: sth IN (...)

Поиск
Список
Период
Сортировка
От Andrzej Zawadzki
Тема Poor performance with queries using clause: sth IN (...)
Дата
Msg-id 4641CB21.2010608@wp.pl
обсуждение исходный текст
Ответы Re: Poor performance with queries using clause: sth IN (...)  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-performance
That's email from my friend.
Any hint?

-------- Original Message --------
Subject: bug
Date: Wed, 09 May 2007 15:03:00 +0200
From: Michal Postupalski
To: Andrzej Zawadzki

We've just changed our database from 8.1 to 8.2 and we are
grief-stricken about very poor performance with queries using clause:
"sth IN (...)". As we can see any query is translate to "sth = ANY
('{....}'::bpchar[]))" and it tooks much more time beacuse it doesn't
use index'es. Why ? How can we speed up these queries? I've just read
"Performance of IN (...) vs. = ANY array[...]" on pgsql-performance
mailing list and I didn't find any solutions. Can anybody tell me what
can I do with postgres to force him using indexes? If there isn't any
solution I'm afraid that we will have to do downgrade to previous
version 8.1.

example:
SELECT count(*)
FROM kredytob b, kredyty k
WHERE true
AND b.kredytid = k.id
AND '' IN ('', upper(b.nazwisko))
AND '' IN ('', upper(b.imie))
AND '78111104485' IN ('', b.pesel)
AND '' IN ('', upper(trim(b.dowseria))) AND '' IN ('', b.dowosnr) AND 0
IN (0, b.typkred) AND k.datazwrot IS NULL;

regards...
Michał Postupalski


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

Предыдущее
От: "Valentine Gogichashvili"
Дата:
Сообщение: Cannot make GIN intarray index be used by the planner
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: Cannot make GIN intarray index be used by the planner