Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons
От | Itagaki Takahiro |
---|---|
Тема | Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons |
Дата | |
Msg-id | AANLkTinE2Cr2ziXPofkLTGzBVtssk8Xp1o1Vwh+E4UO_@mail.gmail.com обсуждение исходный текст |
Ответ на | [PATCH] Custom code int(32|64) => text conversions out of performance reasons (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [PATCH] Custom code int(32|64) => text conversions out
of performance reasons
Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons |
Список | pgsql-hackers |
On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund <andres@anarazel.de> wrote: > While looking at binary COPY performance I forgot to add BINARY and was a bit > shocked to see printf that high in the profile... > > A change from 9192.476ms 5309.928ms seems to be pretty good indication that a > change in that area is waranted given integer columns are quite ubiquous... Good optimization. Here is the result on my machine: * before: 13057.190 ms, 12429.092 ms, 12622.374 ms * after: 8261.688 ms, 8427.024 ms, 8622.370 ms > * I renamed pg_[il]toa to pg_s(16|32|64)toa - I found the names confusing. Not > sure if its worth it. Agreed, but how about pg_i(16|32|64)toa? 'i' might be more popular than 's'. See also http://msdn.microsoft.com/en-US/library/yakksftt(VS.100).aspx I have a couple of questions and comments: * Why did you change "MAXINT8LEN + 1" to "+ 2" ? Are there possibility of buffer overflow in the current code? @@ -158,12 +159,9 @@ int8out(PG_FUNCTION_ARGS) - char buf[MAXINT8LEN + 1]; + char buf[MAXINT8LEN + 2]; * The buffer reordering seems a bit messy. //have to reorder the string, but not 0byte. I'd suggest to fill a fixed-size local buffer from right to left and copy it to the actual output. * C++-style comments should be cleaned up. -- Itagaki Takahiro
В списке pgsql-hackers по дате отправления: