Re: WIP: Make timestamptz_out less slow.

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Make timestamptz_out less slow.
Date: 2015-08-05 13:04:07
Message-ID: CAKJS1f9KA+oEa2o_-5JEib6tgVD+GA4G4qie9xwHxNWKOc44hw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5 August 2015 at 12:51, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
wrote:

> On 29 July 2015 at 03:25, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
>> On 2015-07-29 03:10:41 +1200, David Rowley wrote:
>> > timestamp_out() = 2015-07-29 02:24:33.34 in 3.506000
>> > timestamp_out_old() = 2015-07-29 02:24:33.034 in 64.518000
>> > timestamp_out_af() = 2015-07-29 02:24:33.034 in 2.981000
>> >
>> > timestamp_out_old is master's version, the timestamp_out_af() is yours,
>> and
>> > timestamp_out() is my one. times are in seconds to perform 100 million
>> > calls.
>>
>> That looks good.
>>
>> > So it appears your version is a bit faster than mine, but we're both
>> about
>> > 20 times faster than the current one.
>> > Also mine needs fixed up as the fractional part is not padded the same
>> as
>> > yours, but I doubt that'll affect the performance by much.
>>
>> Worthwhile to finish that bit and try ;)
>>
>> > My view: It's probably not worth going quite as far as you've gone for a
>> > handful of nanoseconds per call, but perhaps something along the lines
>> of
>> > mine can be fixed up.
>>
>> Yes, I agreee that your's is probably going to be fast enough.
>>
>> > Have you thought about what to do when HAVE_INT64_TIMESTAMP is not
>> defined?
>>
>> I don't think it's actually important. The only difference vs float
>> timestamps is that in the latter case we set fsecs to zero BC.
>>
>> Unless we want to slow down the common case it seems not unlikely that
>> we're going to end up with a separate slow path anyway. E.g. neither
>> your version nor mine handles 5 digit years (which is why I fell back to
>> the slow path in that case in my patch).
>>
>
> It occurred to me that handling the 5 digit year is quite a simple change
> to my code:
>
> We simply just need to check if there was any 'num' left after consuming
> the given space. If there's any left then just use pg_uint2str().
> This keeps things very fast for the likely most common case where the year
> is 4 digits long.
>
> I've not thought about negative years. The whole function should perhaps
> take signed ints instead of unsigned.
>
>
I've made a few changes to this to get the fractional seconds part working
as it should.

It also now works fine with 5 digit years.

It's still in the form of the test program, but it should be simple enough
to pull out what's required from that and put into Postgres.

I've also changed my version of AppendSeconds() so that it returns a
pointer to the new end of string. This should be useful as I see some
strlen() calls to get the new end of string. It'll easy to remove those now
which will further increase performance.

timestamp_out() is the proposed new version
timestamp_out_old() is master's version
timestamp_out_af() is your version

Performance is as follows:

With Clang
david(at)ubuntu:~/C$ clang timestamp_out.c -o timestamp_out -O2
david(at)ubuntu:~/C$ ./timestamp_out
timestamp_out() = 2015-07-29 02:24:33.034 in 0.313686
timestamp_out_old() = 2015-07-29 02:24:33.034 in 5.048472
timestamp_out_af() = 2015-07-29 02:24:33.034 in 0.198147

With gcc
david(at)ubuntu:~/C$ gcc timestamp_out.c -o timestamp_out -O2
david(at)ubuntu:~/C$ ./timestamp_out
timestamp_out() = 2015-07-29 02:24:33.034 in 0.405795
timestamp_out_old() = 2015-07-29 02:24:33.034 in 4.678918
timestamp_out_af() = 2015-07-29 02:24:33.034 in 0.270557

Regards

David Rowley
--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
timestamp_out.c text/x-csrc 8.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-08-05 13:08:29 Re: Raising our compiler requirements for 9.6
Previous Message Robert Haas 2015-08-05 12:31:41 Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );