Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons
Date: 2010-11-01 03:04:51
Message-ID: AANLkTinE2Cr2ziXPofkLTGzBVtssk8Xp1o1Vwh+E4UO_@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-11-01 03:10:53 Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons
Previous Message Robert Haas 2010-11-01 03:04:26 Re: [PATCH] More Coccinelli cleanups