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
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 |