Re: planer picks a bad plan (seq-scan instead of index)

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: planer picks a bad plan (seq-scan instead of index)
Дата
Msg-id 45531B36.7030005@archonet.com
обсуждение исходный текст
Ответ на Re: planer picks a bad plan (seq-scan instead of index)  ("Thomas H." <me@alternize.com>)
Список pgsql-general
Thomas H. wrote:
>> Try putting your conditions as part of the join:
>> SELECT * FROM shop.dvds
>> LEFT JOIN
>>   oldtables.movies
>> ON
>>   mov_id = dvd_mov_id
>>   AND (
>>     lower(mov_name) LIKE '%superman re%'
>>     OR lower(dvd_name) like '%superman re%'
>>     OR lower(dvd_edition) LIKE '%superman re%'
>>   )
>> LEFT JOIN shop.data_soundmedia ON sm_info_ean = dvd_ean
>
> unfortunately its getting optimized into the same plan :-)

OK - in that case try explicit subqueries:

SELECT ... FROM
(SELECT * FROM shop.dvds
  LEFT JOIN shop.oldtables.movies
  WHERE lower(mov_name) LIKE ...
) AS bar
LEFT JOIN shop.data_soundmedia

>> I'd also be tempted to look at a tsearch2 setup for the word searches.
>
>
> tsearch2 doesn't work that well for exact matches (including special
> chars). but the culprit here isn't the '%...'%' seqscan, but rather the
> additional joined table (where no lookup except for the join-column
> takes place) that makes the query going from 200ms to 24sec.

Agreed, but I'd still be inclined to let tsearch do a first filter then
limit the results with LIKE.

--
   Richard Huxton
   Archonet Ltd

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

Предыдущее
От: "Sandeep Kumar Jakkaraju"
Дата:
Сообщение: Too many open cursors
Следующее
От: "Anton Melser"
Дата:
Сообщение: Re: autovacuum blues