Re: How to influence the planner
От | Scott Marlowe |
---|---|
Тема | Re: How to influence the planner |
Дата | |
Msg-id | dcc563d10709040711k42c113b0md21f02c4281ade95@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How to influence the planner (Richard Ray <rray@mstc.state.ms.us>) |
Ответы |
Re: How to influence the planner
|
Список | pgsql-sql |
On 8/31/07, Richard Ray <rray@mstc.state.ms.us> wrote: > Changing to enable_seqscan = on does solve this problem, thanks > Is there some method of crafting a query that will assert my wishes to the planner > When is enable_seqscan = off appropriate enable_xxx = off are troubleshooting tools. They override the query planner. For instance, I had a query that was running slow, and using set enable_nestloop=off allowed the query to run fast. However, using explain analyze I could see that the estimated number of rows was off.Analyze didn't fix it, so I increased the stats targetfor the column I was working with, reanalyzed, and voila, the query ran fine with nestloop=on. So, enable_xxx=off is normally only appropriate when troubleshooting an issue, not as a fix all. That's doubly true for enable_seqscan=off. If you do have a query that nothing else seems to work on it, you can set one of the enable_xxx settings off for that connection only and not worry about messing up all the other sessions connecting to your db.
В списке pgsql-sql по дате отправления: