Re: query very slow when enable_seqscan=on

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: query very slow when enable_seqscan=on
Дата
Msg-id 7353.1151967946@sss.pgh.pa.us
обсуждение исходный текст
Ответ на query very slow when enable_seqscan=on  (Tomasz Ostrowski <tometzky@batory.org.pl>)
Ответы Re: query very slow when enable_seqscan=on  (Tomasz Ostrowski <tometzky@batory.org.pl>)
Список pgsql-bugs
Tomasz Ostrowski <tometzky@batory.org.pl> writes:
> I have a very slow query when enable_seqscan=on and very fast when
> enable_seqscan=off.

Here's your problem:

>          ->  Seq Scan on organization  (cost=0.00..480.95 rows=1 width=4) (actual time=0.071..69.702 rows=1892
loops=1)
>                Filter: ((organization_location)::text ~* 'warszawa'::text)

If it were estimating something like the actual number of rows matching
that filter, it'd never have chosen a nestloop plan like that.

How many rows are there in the organization table?

This is probably the fault of the pattern-selectivity heuristic: it's
far too optimistic about long match strings eliminating a lot of rows.
I think there's been some discussion of modifying that logic but no
one's really stepped up with a better idea.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #2510: ERROR: out of memory DETAIL: Failed on request of size 825242672.
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: query very slow when enable_seqscan=on