Re: Performance tuning?
От | Tom Lane |
---|---|
Тема | Re: Performance tuning? |
Дата | |
Msg-id | 19503.1179617519@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Performance tuning? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
I wrote: > Another thing that might be worth fixing is the rather silly use of '%%%' > rather than '%' for a no-op LIKE pattern. It looks like the planner's > LIKE-estimator gets fooled by that and doesn't realize it's a > match-everything pattern. Uh, scratch that advice, I fat-fingered my test. It does seem to estimate that '%%%' matches every row. But that leads into another question, because some of the scan estimates are further off than one would like: >> -> Seq Scan on tblclientcomments (cost=0.00..40651.36 rows=601579 width=17) (actual time=0.014..17.342rows=6912 loops=1017) >> Filter: (((fldproductcode)::text ~~* '%%%'::text) AND (fldenable = true)) I had thought that this was explained by a bad LIKE estimate but that seems not the case, which means that your statistics for fldenable must be way off. Have you ANALYZEd these tables since loading the data? regards, tom lane
В списке pgsql-general по дате отправления: