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 по дате отправления: