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

Re: code cleanup of timestamp code

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Warren Turkal <turkal(at)google(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: code cleanup of timestamp code
Date: 2008-02-26 19:55:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Tue, 2008-02-26 at 00:22 -0800, Warren Turkal wrote:
>> As a result, I have a few questions about the timestamp code. In what
>> instances is the floating point timestamp recommended?

> One circumstance is when there isn't a native int64 type available.

There are other possible reasons to prefer the float implementation;
for example it has wider range than the int64 code.  Most people have
no need to represent dates beyond 6 million AD, of course, but I think
it's at least potentially useful for some scientific applications.

Also, despite the Niagara-centric moans you may have noticed from some
Sun hackers, float arithmetic is faster than int64 on quite a wide
variety of recent hardware.  That may sound counterintuitive but float
units have been a traditional place to fling any surplus of gates at,
while if you don't have 64-bit hardware then int64 isn't really a native
type.  MegaFLOP ratings are marketable, mega-int64-ops not so much.
(Though it's possibly true that the actual arithmetic in datetime.c is
buried under too much logic for it to make a noticeable difference :-()

Anyway I think they both have their place.  int64 is a sensible default,
because it doesn't have the type of non-decimal behavior that tends
to surprise novices (compare today's bug #3991).  But I don't see float
disappearing entirely.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-02-26 20:03:47
Subject: Re: pg_dump additional options for performance
Previous:From: Simon RiggsDate: 2008-02-26 19:55:29
Subject: Re: pg_dump additional options for performance

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