Thread: TransactionStateData and AbsoluteTime

Hi, I'm wondering why the transaction star time in
TransactionStateData is Absolutetime.  From nabstime.h:
* Although time_t generally is a long int on 64 bit systems, these two* types must be 4 bytes, because that's what the
systemassumes. They* should be yanked (long) before 2038 and be replaced by timestamp and* interval.*/
 
typedef int32 AbsoluteTime;
typedef int32 RelativeTime;

Shouldn't we use timestamp instead of AbsoluteTime in
TransactionStateData?  It also gives more precision.
--
Tatsuo Ishii

Tatsuo Ishii writes:

> Shouldn't we use timestamp instead of AbsoluteTime in
> TransactionStateData?  It also gives more precision.

Thomas was hesitant to using 8 byte types internally across the board. He
must have his reasons.

I think that eventually *all* time'ish stuff should be moved to the new
stuff but perhaps we should wait until the current datetime-related panic
has died down. :)

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

> > Shouldn't we use timestamp instead of AbsoluteTime in
> > TransactionStateData?  It also gives more precision.
> Thomas was hesitant to using 8 byte types internally across the board. He
> must have his reasons.

Yes, I believe that I discussed it at that time, though not perhaps
all of these points:

I was hesitant to suggest a change which would increase the minimum
size of a tuple.

I was hesitant to tie the fundamental internal operation to modern
floating point performance on machines (it is only recently that float
calculations are comparable to ints).

On 64 bit machines especially, it may be interesting to do a 64 bit
int for the date/time types, which would give greater precision away
from Y2K, but a more limited total range.

To get a precision greater than 1 second, we would have to use a
different time call from the OS. I assume that one would be fairly
portable, but would then require a conversion of int8 to float, with
some runtime expense.

And I haven't seen a great demand for greater precision in the table
structures, though istm that it might be of interest.
                     - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

> > > Shouldn't we use timestamp instead of AbsoluteTime in
> > > TransactionStateData?  It also gives more precision.
> > Thomas was hesitant to using 8 byte types internally across the board. He
> > must have his reasons.
> 
> Yes, I believe that I discussed it at that time, though not perhaps
> all of these points:
> 
> I was hesitant to suggest a change which would increase the minimum
> size of a tuple.

Can you tell me where the data/time info exists in HeapTupleData?
I could not find it.

> I was hesitant to tie the fundamental internal operation to modern
> floating point performance on machines (it is only recently that float
> calculations are comparable to ints).
> 
> On 64 bit machines especially, it may be interesting to do a 64 bit
> int for the date/time types, which would give greater precision away
> from Y2K, but a more limited total range.
> 
> To get a precision greater than 1 second, we would have to use a
> different time call from the OS. I assume that one would be fairly
> portable, but would then require a conversion of int8 to float, with
> some runtime expense.

Ok. currently we call GetCurrentAbsoluteTime() to get the transaction
start time. If we use timestamp instead of Abstime, we would call
timeofday() defined in nabstime.c or something like that. So it might
be interesting to see how the speed is different between these two
calls. If I have a spare time, I'll try it.

> And I haven't seen a great demand for greater precision in the table
> structures, though istm that it might be of interest.

Anyway, I think we don't want to see those none trivial changes to
appear in 7.0.
--
Tatsuo Ishii