Re: fixes for date_part micro/millisecond precision

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: thomas(at)pgsql(dot)com
Cc: Brent Verner <brent(at)rcfile(dot)org>, Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>, pgsql-patches(at)postgresql(dot)org
Subject: Re: fixes for date_part micro/millisecond precision
Date: 2001-11-28 04:44:05
Message-ID: 856.1006922645@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> I have been thinking of implementing timestamp (and other related types)
> as 8 byte integers, which are not slow on some platforms. doubles are
> fast on most platforms nowadays.

OTOH, 8 byte integers fail to exist at all on some other platforms.

I'd be in favor of reimplementing timestamps as int8 if it weren't for
the portability issue. But I'm not sure I want to blow off int8-less
platforms quite yet.

> The tradeoff will be repeatability vs
> range, since we will not get the quasi-infinite range we have now when
> using a fixed decimal type.

If we didn't mind increasing the storage requirement, we could do
"float8 for the integral seconds, plus an int4 for the nanoseconds",
which would work perfectly out to about 2^52 seconds either way from the
epoch, and continue to work with reduced accuracy until the heat death
of the universe. But this would be 12 bytes, plus 4 bytes alignment
padding on some platforms, which might be excessive just to guarantee
nanosecond precision out to the next geological era.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Thomas Lockhart 2001-11-28 05:07:44 Re: fixes for date_part micro/millisecond precision
Previous Message Thomas Lockhart 2001-11-28 03:40:05 Re: fixes for date_part micro/millisecond precision