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-09-08 00:34:59
Message-ID: CAKJS1f96+ByOQpM0ETtg8fWeO68OUdMB-p_GzYoipL5Y3dLWUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3 September 2015 at 22:17, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2015-09-03 16:28:40 +1200, David Rowley wrote:
> > > Wouldn't it be better to just normalize fsec to an integer in that
> case?
> > > Afaics that's the only remaining reason for the alternative path?
> > >
> > > A special case would need to exist somewhere, unless we just modified
> > timestamp2tm() to multiply fsec by 1 million when HAVE_INT64_TIMESTAMP is
> > not defined, but that changes the function signature.
>
> Sure, but that's a one line #ifdef?
>

I had a look at this but I found that the precision is 10 with double
timestamps per:

#define MAX_TIME_PRECISION 10
#define TIME_PREC_INV 10000000000.0

So if I do something like:

int fseconds = fsec * TIME_PREC_INV;

In AppendSeconds(), it overflows fseconds.

I could of course make fseconds an int64, but then I'll need to include a
64bit version of pg_int2str(). That does not seem like an improvement.

I'm also starting to not like the name pg_int2str(), It may cause confusion
with 2 bytes, instead of convert "2".

Regards

David Rowley

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2015-09-08 00:57:05 Re: pg_hba_lookup function to get all matching pg_hba.conf entries
Previous Message Alvaro Herrera 2015-09-08 00:32:28 Re: [COMMITTERS] pgsql: contrib/sslinfo: add ssl_extension_info SRF