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

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Subject: Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons
Date: 2010-11-02 00:37:43
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Monday 01 November 2010 10:15:01 Andres Freund wrote:
> On Monday 01 November 2010 04:04:51 Itagaki Takahiro wrote:
> > 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...
> > > * 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
> >
> I find itoa not as clear about signedness as stoa, but if you insist, I
> dont feel strongly about it.
Let whover commits it decide...

> > * 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.
> Is a bit cleaner maybe, but I dont see much point in putting it into its
> own function... But again, I don't feel strongly.
Using a seperate buffer cost nearly 500ms... So I only changed the comments

The only way I could think of to make it faster was to fill the buffer from the
end and then return a pointer to the starting point in the buffer. The speed
benefits are small (around 80ms) and it makes the interface more cumbersome...

Revised version attached - I will submit this to the next comittfest now.


Attachment Content-Type Size
Implement-custom-int-248-string-conversion-routines-V2.patch text/x-patch 9.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Hunsaker 2010-11-02 00:40:00 Re: why does plperl cache functions using just a bool for is_trigger
Previous Message Hiroshi Inoue 2010-11-01 23:43:35 Re: Complier warnings on mingw gcc 4.5.0