Re: WIP: Make timestamptz_out less slow.
| От | David Rowley |
|---|---|
| Тема | Re: WIP: Make timestamptz_out less slow. |
| Дата | |
| Msg-id | CAKJS1f96+ByOQpM0ETtg8fWeO68OUdMB-p_GzYoipL5Y3dLWUw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: WIP: Make timestamptz_out less slow. (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
On 3 September 2015 at 22:17, Andres Freund <andres@anarazel.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/
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: