Re: [PERFORM] Performance analysis of plpgsql code

2005-06-27 Thread Michael Fuhr
On Tue, Jun 28, 2005 at 03:03:06AM +, Karl O. Pinc wrote: > > For all your work a documentation patch is appended that > I think is easier to read and might avoid this problem > in the future. Patches should go to the pgsql-patches list -- the people who review and apply patches might not be

Re: [PERFORM] Performance analysis of plpgsql code

2005-06-27 Thread Karl O. Pinc
On 06/27/2005 08:34:19 PM, Michael Fuhr wrote: On Tue, Jun 28, 2005 at 01:54:08AM +, Karl O. Pinc wrote: > On 06/27/2005 06:33:03 PM, Michael Fuhr wrote: > > >See timeofday(). > > That only gives you the time at the start of the transaction, > so you get no indication of how long anything in

Re: [PERFORM] Performance analysis of plpgsql code

2005-06-27 Thread Michael Fuhr
On Tue, Jun 28, 2005 at 01:54:08AM +, Karl O. Pinc wrote: > On 06/27/2005 06:33:03 PM, Michael Fuhr wrote: > > >See timeofday(). > > That only gives you the time at the start of the transaction, > so you get no indication of how long anything in the > transaction takes. Did you read the docum

Re: [PERFORM] Performance analysis of plpgsql code

2005-06-27 Thread Michael Glaesemann
On Jun 28, 2005, at 10:54 AM, Karl O. Pinc wrote: On 06/27/2005 06:33:03 PM, Michael Fuhr wrote: On Mon, Jun 27, 2005 at 11:30:45PM +, Karl O. Pinc wrote: > > Short of that I think I'm going to be reduced to > writing a C function that returns the real > system time so I can spatter my c

Re: [PERFORM] Performance analysis of plpgsql code

2005-06-27 Thread Karl O. Pinc
On 06/27/2005 06:33:03 PM, Michael Fuhr wrote: On Mon, Jun 27, 2005 at 11:30:45PM +, Karl O. Pinc wrote: > > Short of that I think I'm going to be reduced to > writing a C function that returns the real > system time so I can spatter my code with > RAISE statements that indicate actual execu

Re: [PERFORM] Performance analysis of plpgsql code

2005-06-27 Thread Michael Fuhr
On Mon, Jun 27, 2005 at 11:30:45PM +, Karl O. Pinc wrote: > > Short of that I think I'm going to be reduced to > writing a C function that returns the real > system time so I can spatter my code with > RAISE statements that indicate actual execution > time. See timeofday(). http://www.postgr

[PERFORM] Performance analysis of plpgsql code

2005-06-27 Thread Karl O. Pinc
Hi, I'm having a hard time finding the poorly performing statements in my plpgsql procedures, many of which are triggers. Am I missing something? I can get the query plans by starting up a new connection and doing: SET DEBUG_PRINT_PLAN TO TRUE; SET CLIENT_MIN_MESSAGES TO DEBUG1; And then runnin