Re: horrendous query challenge :-)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fran Fabrizio <ffabrizio(at)mmrd(dot)com>
Cc: Shaun Thomas <sthomas(at)townnews(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: horrendous query challenge :-)
Date: 2002-05-30 19:12:06
Message-ID: 2536.1022785926@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I said:
> Your .003 is an overestimate since it includes all the overhead
> of query parsing/planning, but it still appears that those function
> calls are the bulk of the runtime.

BTW, a more accurate estimate of function execution time could be had
like this:

regression=# select timeofday(), timeofday();
timeofday | timeofday
-------------------------------------+-------------------------------------
Thu May 30 15:05:32.838542 2002 EDT | Thu May 30 15:05:32.838718 2002 EDT
(1 row)

regression=# select 838718-838542;
?column?
----------
176
(1 row)

regression=# select timeofday(), recursion_test(22,42), timeofday();
timeofday | recursion_test | timeofday
-------------------------------------+-------------------------------------------------------------+-------------------------------------
Thu May 30 15:05:57.342504 2002 EDT | 22,21,20,19,18,17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,42 | Thu May 30 15:05:57.347398 2002 EDT
(1 row)

regression=# select 347398-342504;
?column?
----------
4894
(1 row)

so I can conclude that recursion_test() took about 4.7 msec.

On my machine this technique seems to yield measurements good to 10
microsec or so. Note you have to use timeofday() and not now().

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jean-Luc Lachance 2002-05-30 19:16:30 Re: Scaling with memory & disk planning
Previous Message Dan Weston 2002-05-30 19:11:21 Re: connection refused problem