Re: not exactly a bug report, but surprising behaviour - Mailing list pgsql-general

From Tom Lane
Subject Re: not exactly a bug report, but surprising behaviour
Date
Msg-id 8878.1044502805@sss.pgh.pa.us
Whole thread Raw
In response to Re: not exactly a bug report, but surprising behaviour  (Greg Stark <gsstark@mit.edu>)
Responses Re: not exactly a bug report, but surprising behaviour  (Greg Stark <gsstark@mit.edu>)
List pgsql-general
Greg Stark <gsstark@mit.edu> writes:
> Neil Conway <neilc@samurai.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

pgsql-general by date:

Previous
From: "Cornelia Boenigk"
Date:
Subject: Re: IN() alternatives
Next
From: John Smith
Date:
Subject: Re: Deleting orphan records