Re: [PERFORM] function slower than the same code in an sql file

2011-11-03 Thread CS DBA
On 11/03/2011 09:40 AM, Robert Haas wrote: On Thu, Nov 3, 2011 at 11:31 AM, Rodrigo Gonzalez wrote: El 03/11/11 11:42, Robert Haas escribió: On Fri, Oct 28, 2011 at 9:39 AM, CS DBA wrote: No parameters, one of them looks like this: [ code snippet ] It's hard to believe this is the real c

Re: [PERFORM] function slower than the same code in an sql file

2011-11-03 Thread Robert Haas
On Thu, Nov 3, 2011 at 11:31 AM, Rodrigo Gonzalez wrote: > El 03/11/11 11:42, Robert Haas escribió: > > On Fri, Oct 28, 2011 at 9:39 AM, CS DBA wrote: > > No parameters,  one of them looks like this: > > [ code snippet ] > > It's hard to believe this is the real code, because SELECT without > INT

Re: [PERFORM] function slower than the same code in an sql file

2011-11-03 Thread Rodrigo Gonzalez
El 03/11/11 11:42, Robert Haas escribió: On Fri, Oct 28, 2011 at 9:39 AM, CS DBA wrote: No parameters, one of them looks like this: [ code snippet ] It's hard to believe this is the real code, because SELECT without INTO will bomb out inside a PL/pgsql function, won't it? But he's using CR

Re: [PERFORM] function slower than the same code in an sql file

2011-11-03 Thread Robert Haas
On Fri, Oct 28, 2011 at 9:39 AM, CS DBA wrote: > No parameters,  one of them looks like this: > > [ code snippet ] It's hard to believe this is the real code, because SELECT without INTO will bomb out inside a PL/pgsql function, won't it? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com

Re: [PERFORM] function slower than the same code in an sql file

2011-10-28 Thread CS DBA
On 10/27/2011 11:10 PM, Tom Lane wrote: CS DBA writes: I have code that drops a table, re-create's it (based on a long set of joins) and then re-creates the indexes. It runs via psql in about 10 seconds. I took the code and simply wrapped it into a plpgsql function and the function version tak

Re: [PERFORM] function slower than the same code in an sql file

2011-10-27 Thread Pavel Stehule
Hello plpgsql uses a cached prepared plans for queries - where optimizations is based on expected values - not on real values. This feature can do performance problems some times. When you have these problems, then you have to use a dynamic SQL instead. This generate plans for only one usage and

Re: [PERFORM] function slower than the same code in an sql file

2011-10-27 Thread Tom Lane
CS DBA writes: > I have code that drops a table, re-create's it (based on a long set of > joins) and then re-creates the indexes. > It runs via psql in about 10 seconds. I took the code and simply > wrapped it into a plpgsql function and the function version takes almost > 60 seconds to run.