Re: Enabling and disabling run time configuration parameters.
От | Bruno Wolff III |
---|---|
Тема | Re: Enabling and disabling run time configuration parameters. |
Дата | |
Msg-id | 20030605161502.GA22114@wolff.to обсуждение исходный текст |
Ответ на | Enabling and disabling run time configuration parameters. (Yusuf <yusuf0478@netscape.net>) |
Список | pgsql-performance |
On Thu, Jun 05, 2003 at 11:35:22 -0400, Yusuf <yusuf0478@netscape.net> wrote: > I have discovered that I could optimize queries by adjusting the > following parameters such as enable_seqscan, enable_hashjoin, > enable_mergejoin and enable_nestloop. > > Is it a good idea, to temporarily adjust those values before running a > query to spend up the execution time? I've searched online and wasn't > able to find articles about it. That is a reasonable thing to do. However you should also look into adjusting some of the costs used by the planner so that it gets the right plan more often. If you manually hack how the query is done, then you have to worry about whether the hack is still right if the the data changes significantly. > I need to speed up an enterprise application that I'm working on, and I > wouldn't want to screw things up. There worst that would happen is that the plan you forced it to use was slower than what the planner would have used. > My plan is for every query that could be optimized by adjusting > parameters: I'll enable parameters that'll speed it up, run the query, > then set the parameters back to their default values. They only apply to the current backend session. You can also set them for just the current transaction which is safer if you are using persistant backend connections. (So that if you make a mistake the setting doesn't apply for a very long time.)
В списке pgsql-performance по дате отправления: