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)
|
Список | 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 по дате отправления: