Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?
В списке pgsql-performance по дате отправления:
| От | Robert Haas |
|---|---|
| Тема | Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk? |
| Дата | |
| Msg-id | 603c8f071002150841w53cda2f6l7901e7af06da862@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: 512,600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk? (Bryce Nesbitt <bryce2@obviously.com>) |
| Список | pgsql-performance |
On Sat, Feb 13, 2010 at 2:58 AM, Bryce Nesbitt <bryce2@obviously.com> wrote: > So as the op, back to the original posting.... > > In the real world, what should I do? Does it make sense to pull the "AND > articles.indexed" clause into an outer query? Will that query simply > perform poorly on other arbitrary combinations of words? It's really hard to say whether a query that performs better is going to always perform better on every combination of words. My suggestion is - try it and see. It's my experience that rewriting queries is a pretty effective way of speeding them up, but I can't vouch for what will happen in your particular case. It's depressing to see that increasing the statistics target didn't help much; but that makes me think that the problem is that your join selectivity estimates are off, as Tom and Jorge said upthread. Rewriting the query or trying an upgrade are probably your only options. ...Robert
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера