Thread: How check execution plan of a function
Hi there, I have a function which returns setof record based on a specific query. I try to check the execution plan of that query, so I write EXPLAIN ANALYZE before my select, I call the function and I see the result which shows an actual time about 5 seconds. But when I call my function after I remove EXPLAIN ANALYZE it takes more than 300 seconds, and I cancel it. What's happen, or how can I see the function execution plan to optimize it ? TIA, Sabin
Maybe other details about the source of the problem help. The problem occured when I tried to optimize the specified function. It was running in about 3 seconds, and I needed to be faster. I make some changes and I run the well known "CREATE OR REPLACE FUNCTION ..." After that, my function execution took so much time that I had to cancel it. I restored the previous function body, but the problem persisted. I tried to drop it and create again, but no chance to restore the original performance. So I was forced to restore the database from backup. Also I found the problem is reproductible, so a change of function will damage its performance. Can anyone explain what is happen ? How can I found the problem ? TIA, Sabin
On Wed Apr 7 2010 7:47 AM, Sabin Coanda wrote: > Hi there, > > I have a function which returns setof record based on a specific query. > I try to check the execution plan of that query, so I write EXPLAIN ANALYZE > before my select, I call the function and I see the result which shows an > actual time about 5 seconds. But when I call my function after I remove > EXPLAIN ANALYZE it takes more than 300 seconds, and I cancel it. > > What's happen, or how can I see the function execution plan to optimize it ? > > TIA, > Sabin > > I ran into the same problems, what I did was enable the logging in postgresql.conf. I dont recall exactly what I enabled, but it was something like: track_functions = pl log_statement_stats = on log_duration = on Then in the serverlog you can see each statement, and how long it took. Once I found a statement that was slow I used explain analyze on just it so I could optimize that one statement. -Andy
On Fri Apr 9 2010 8:18 AM, Sabin Coanda wrote: > I have just a function returning a cursor based on a single coplex query. > When I check the execution plan of that query it takes about 3 seconds. Just > when it is used inside the function it freezes. > > This is the problem, and this is the reason I cannot imagine what is happen. > Also I tried to recreate the function as it was before when it run in 3 > seconds, but I cannot make it to run properly now. > > a query, like: "select stuff from aTable where akey = 5" can be planned/prepared differently than a function containing: "select stuff from aTable where akey = $1". I'm guessing this is the problem you are running into. The planner has no information about $1, so cannot make good guesses. I think you have two options: 1) dont use a function, just fire off the sql. 2) inside the function, create the query as a string, then execute it, like: a := "select junk from aTable where akey = 5"; EXECUE a; (I dont think that's the exact right syntax, but hopefully gets the idea across) -Andy
I have just a function returning a cursor based on a single coplex query. When I check the execution plan of that query it takes about 3 seconds. Just when it is used inside the function it freezes. This is the problem, and this is the reason I cannot imagine what is happen. Also I tried to recreate the function as it was before when it run in 3 seconds, but I cannot make it to run properly now.
"Sabin Coanda" <sabin.coandaSPAMPROTECTION@deuromedia.ro> wrote: > I have just a function returning a cursor based on a single coplex > query. When I check the execution plan of that query it takes > about 3 seconds. Just when it is used inside the function it > freezes. > > This is the problem, and this is the reason I cannot imagine what > is happen. > > Also I tried to recreate the function as it was before when it run > in 3 seconds, but I cannot make it to run properly now. You've given three somewhat confusing and apparently contradictory descriptions of the problem or problems you've had with slow queries -- all on one thread. You would probably have better luck if you start with one particular issue and provided more of the information suggested here: http://wiki.postgresql.org/wiki/SlowQueryQuestions If we can solve one problem, perhaps the resolution to the others will become apparent; otherwise follow up with the next. -Kevin