From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: not exactly a bug report, but surprising behaviour |
Date: | 2003-02-06 03:40:05 |
Message-ID: | 8878.1044502805@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Neil Conway <neilc(at)samurai(dot)com> writes:
>> On Wed, 2003-02-05 at 15:49, Greg Stark wrote:
> % cumulative self self total
> time seconds seconds calls s/call s/call name
> 16.59 97.88 97.88 69608411 0.00 0.00 ExecMakeFunctionResult
> 7.08 139.65 41.77 79472258 0.00 0.00 comparetup_heap
> 4.50 166.17 26.52 192211935 0.00 0.00 ExecEvalExpr
>>
>> Annoyingly enough, I get similarly strange gprof output (all zeros in
>> the two right hand columns) on Debian --
> Well this is Debian also, but I don't think that's related.
Right. Zeroes in the per-call columns are not unexpected. If you get
zeroes in the "self seconds" or "calls" fields then you have a
measurement issue ... but what we're seeing here is just ye olde death
of a thousand cuts, viz a lot of calls on routines that don't take very
long in any one call.
It is annoying that ExecMakeFunctionResult seems to be chewing so much
CPU time, since it's nothing more than an interface routine. But
offhand I have no ideas on how to improve the situation.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Smith | 2003-02-06 04:27:00 | Re: Deleting orphan records |
Previous Message | Cornelia Boenigk | 2003-02-06 02:42:51 | Re: IN() alternatives |