From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Floating-point timestamps versus Range Types |
Date: | 2010-10-22 02:24:45 |
Message-ID: | 11781.1287714285@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Itagaki Takahiro | 2010-10-22 02:28:11 | Re: Extensions, this time with a patch |
Previous Message | Robert Haas | 2010-10-22 02:17:14 | Re: Simplifying replication |