> > > 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.
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2000-03-07 03:31:56|
|Subject: Re: [HACKERS] Proposal for Grand Unified Configuration scheme|
|Previous:||From: Tatsuo Ishii||Date: 2000-03-07 01:07:16|
|Subject: Re: [HACKERS] sqgfault on initdb with current CVS|