On 3 September 2015 at 05:10, Andres Freund <and...@anarazel.de> wrote:
> > +/*
> > + * 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
Regards
David Rowley
timestamp_delta.patch
Description: Binary data
timestamp_out_speedup_2015-09-12.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
