Re: not exactly a bug report, but surprising behaviour
От | Tom Lane |
---|---|
Тема | Re: not exactly a bug report, but surprising behaviour |
Дата | |
Msg-id | 8878.1044502805@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: not exactly a bug report, but surprising behaviour (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: not exactly a bug report, but surprising behaviour
|
Список | 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 по дате отправления: