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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons
Date: 2010-11-19 21:16:19
Message-ID: 201011192216.20066.andres@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Monday 15 November 2010 17:12:25 Robert Haas wrote:> I notice that int8out
isn't terribly consistent with int2out and
> int4out, in that it does an extra copy. Maybe that's justified given
> the greater potential memory wastage, but I'm not certain. One
> approach might be to pick some threshold value and allocate a buffer
> in one of two sizes based on how large the value is relative to that
> cutoff. But that might also be a stupid idea, not sure.
I removed the extra buffer - its actually a tiny bit faster without it (I
guess the allocation pattern is a bit nicer during copy as it will always take
the same paths and eventually the same address).
I couldn't measure any difference memory-usage wise.

The code was that way before btw.

> It would speed things up for me if you or someone else could take a
> quick pass over what remains here and fix the formatting and
> whitespace to be consistent with our general project style, and make
> the comment headers more consistent among the functions being
> added/modified.
I think I did most of those - the function comments in numutils weren't
consistent before - now its consistent with the unchanged pg_atoi.

Thanks for reviewing/applying the first part,

Andres

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message José Arthur Benetasso Villanova 2010-11-19 21:28:03 Re: directory archive format for pg_dump
Previous Message Caleb.Welton 2010-11-19 21:11:56 Re: UNNEST ... WITH ORDINALITY (AND POSSIBLY OTHER STUFF)