Re: same plan, add 1 condition, 1900x slower

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: same plan, add 1 condition, 1900x slower
Дата
Msg-id 10164.1131643400@sss.pgh.pa.us
обсуждение исходный текст
Ответ на same plan, add 1 condition, 1900x slower  (Mitch Skinner <mitch@egcrc.net>)
Ответы Re: same plan, add 1 condition, 1900x slower  (Mitch Skinner <mitch@egcrc.net>)
Список pgsql-performance
Mitch Skinner <mitch@egcrc.net> writes:
> This is with Postgres 8.0.3.  Any advice is appreciated.

These are exactly the same plan, except for the addition of the extra
filter condition ...

>    ->  Index Scan using external_id_map_primary_key on external_id_map
> eim  (cost=0.00..2345747.01 rows=15560708 width=26) (actual
> time=0.061..2.944 rows=2175 loops=1)

>    ->  Index Scan using external_id_map_primary_key on external_id_map
> eim  (cost=0.00..2384648.78 rows=4150 width=26) (actual
> time=0.020..21068.508 rows=1186 loops=1)
>          Filter: (source = 'SCH'::bpchar)

Apparently, you are using a platform and/or locale in which strcoll() is
spectacularly, god-awfully slow --- on the order of 10 msec per comparison.
This is a bit hard to believe but I can't make sense of those numbers
any other way.  What is the platform exactly, and what database locale
and encoding are you using?

            regards, tom lane

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

Предыдущее
От: mark@mark.mielke.cc
Дата:
Сообщение: Re: WAL sync behaviour
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WAL sync behaviour