Re: planer picks a bad plan (seq-scan instead of index) - Mailing list pgsql-general

From Richard Huxton
Subject Re: planer picks a bad plan (seq-scan instead of index)
Date
Msg-id 45531B36.7030005@archonet.com
Whole thread Raw
In response to Re: planer picks a bad plan (seq-scan instead of index)  ("Thomas H." <me@alternize.com>)
List 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 by date:

Previous
From: "Sandeep Kumar Jakkaraju"
Date:
Subject: Too many open cursors
Next
From: "Anton Melser"
Date:
Subject: Re: autovacuum blues