Re: not exactly a bug report, but surprising behaviour

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

In response to

Responses

Browse pgsql-general by date

  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