Re: Floating-point timestamps versus Range Types - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Floating-point timestamps versus Range Types
Date
Msg-id AANLkTimkJqvcQLfDgMOLjQ0sJjn7AC5ypOhyugQHaNWx@mail.gmail.com
Whole thread Raw
In response to Re: Floating-point timestamps versus Range Types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Oct 21, 2010 at 10:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> Greg Stark wrote:
>>> Did we have a solution for the problem that understanding which
>>> columns are timestamps requires having a tuple descriptor and parsing
>>> the every tuple? That seems like it would a) be slow and b) require a
>>> lot of high level code in the middle of a low-level codepath.
>
>> Yep, that's what it requires.  It would rewrite in the new format.
>
> In the case of the recent hstore fixes, we were able to put the burden
> on the hstore functions themselves to do any necessary conversion.
> I wonder if it'd be possible to do something similar here?  I haven't
> chased the bits in any detail, but I'm thinking that integer timestamps
> in a plausible range might all look like denormalized floats, and
> conversely plausible float timestamps would look like ridiculously large
> integer timestamps.  Would we be willing to make such assumptions to
> support in-place upgrade of timestamps?

This seems like it might not be entirely reliable, which would make me
disinclined to do it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Floating-point timestamps versus Range Types
Next
From: Fujii Masao
Date:
Subject: Re: Timeout and wait-forever in sync rep