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

Search Discussions

  • Peter Eisentraut at Mar 5, 2000 at 1:37 pm

    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
  • Thomas Lockhart at Mar 6, 2000 at 11:04 pm

    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
  • Tatsuo Ishii at Mar 7, 2000 at 1:35 am

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMar 5, '00 at 1:47a
activeMar 7, '00 at 1:35a
posts4
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase