Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Дата
Msg-id 22214.1358104672@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> the numbers are:
> old definition:                                 10393.658ms, 5497912 bytes
> old definition + unreachable:                   10011.102ms, 5469144 bytes
> stmt, two calls, unreachable:                   10036.132ms, 5468792 bytes
> stmt, one call, unreachable:                    9443.612ms,  5462232 bytes
> stmt, one call, unreachable, save errno:        9615.863ms,  5489688 bytes

I find these numbers pretty hard to credit.  Why should replacing two
calls by one, in code paths that are not being taken, move the runtime
so much?  The argument that a net reduction of code size is a win
doesn't work, because the last case is more code than any except the
first.

I think you're measuring some coincidental effect or other, not a
reproducible performance improvement.  Or there's a bug in the code
you're using.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)