Skip site navigation (1) Skip section navigation (2)

Re: fixes for date_part micro/millisecond precision

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: thomas(at)pgsql(dot)com, 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 05:07:44
Message-ID: 3C047120.7F15A6C8@fourpalms.org (view raw or flat)
Thread:
Lists: pgsql-patches
> > 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.

Sure. It would be selectable at configure/build time. Failing to support
int64 would mean you don't get the integer alternative for timestamp
either.

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

Yes. Mixing the float with the int seems to invite math troubles though
(as does the struct solution of using two ints, since roundoff and
carryover might be troublesome).

Just a thought for now, but the int8 alternative may be pretty easy to
do.

                        - Thomas

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2001-11-28 05:13:22
Subject: Re: fixes for date_part micro/millisecond precision
Previous:From: Tom LaneDate: 2001-11-28 04:44:05
Subject: Re: fixes for date_part micro/millisecond precision

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group