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  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: "Cornelia Boenigk"
Дата:
Сообщение: Re: IN() alternatives
Следующее
От: John Smith
Дата:
Сообщение: Re: Deleting orphan records