> +/* > + * pg_int2str > + * Converts 'value' into a decimal string representation of the number. > + * > + * Caller must ensure that 'str' points to enough memory to hold the result > + * (at least 12 bytes, counting a leading sign and trailing NUL). > + * Return value is a pointer to the new NUL terminated end of string. > + */ > +char * > +pg_int2str(char *str, int32 value) > +{ > + char *start; > + char *end; > + > + /* > + * Handle negative numbers in a special way. We can't just append a '-' > + * prefix and reverse the sign as on two's complement machines negative > + * numbers can be 1 further from 0 than positive numbers, we do it this way > + * so we properly handle the smallest possible value. > + */ > + if (value < 0) > + {
We could alternatively handle this by special-casing INT_MIN, probably resulting in a bit less duplicated code.
Hi Andres,
I've made a few updates to the patch to cleanup a few badly written comments, and also to fix a missing Abs() call.
I've also renamed the pg_int2str to become pg_ltostr() to bring it more inline with pg_ltoa.
Attached is also timestamp_delta.patch which changes pg_ltostr() to use the INT_MIN special case that pg_ltoa also uses. I didn't make a similar change to pg_ltostr_zeropad() as I'd need to add even more special code to prepend the correct number of zero before the 2147483648. This zero padding reason was why I originally came up with the alternative way to handle the negative numbers. I had just thought that it was best to keep both functions as similar as possible.
I've not done anything yet to remove the #ifdef HAVE_INT64_TIMESTAMP from AppendSeconds(). The only way I can think to handle this is to just make fsec_t unconditionally an int64 (since with float datetimes the precision is 10 decimal digits after the dec point, this does not fit in int32). I'd go off and do this, but this means I need to write an int64 version of pg_ltostr(). Should I do it this way?
I also did some tests on server grade hardware, and the performance increase is looking a bit better.
create table ts (ts timestamp not null);
insert into ts select generate_series('2010-01-01 00:00:00', '2011-01-01 00:00:00', '1 sec'::interval);
vacuum freeze ts;
Master
tpch=# copy ts to '/dev/null';
COPY 31536001
Time: 17071.255 ms
Patched
tpch=# copy ts to '/dev/null';
COPY 31536001
Time: 6402.835 ms
The times don't seem to vary any depending on the attached timestamp_delta.patch
