Thread: Configuring for 64-bit integer date/time storage?

I've got patches to enable storage of date/time values as integers
rather than as floating point numbers, as discussed earlier. 64-bit
integers are (afaik) not available on every platform we want to support,
and there *may* be a performance difference depending on the processor
and compiler involved (I haven't run focused timing tests yet), so we
will want the original floating point implementation to continue to be
available.

For development, I've just defined HAVE_INT64_TIMESTAMP (probably should
become HAVE_INT64_DATETIMES or something like that?) in my
Makefile.custom, but of course this should become some combination of
command-line option and perhaps a consistancy check in the configuration
process. afaict configure.in and pg_config.h.in are the interesting
files for this.

I've got questions:

1) For the ./configure command line option, does
--enable-integer-datetimes seem OK, or could someone suggest a better
choice? --enable-integer-datetimes is a longer string than any of the
other options, so a less wordy possibility may be better.

2) Actually using integer date/time storage depends on whether 64-bit
integers are really supported. So although they may be enabled, it may
not be supported. Should ./configure error out at that point, or should
things gracefully (silently?) configure to use the existing floating
point implementation? See (3).

3) ./configure checks for several different styles of 64-bit integers to
see what is actually supported. But it does not control whether an
overall "yes we have some kind of 64-bit integer" flag gets defined. So
detecting an inconsistancy in enabling 64-bit integer storage on
machines without 64-bit integers seems to be out of the scope of
./configure. Correct?

I could keep asking variations on these same questions, so feel free to
add answers to questions which weren't asked ;)
                   - Thomas

Thomas Lockhart <thomas@fourpalms.org> writes:
> 1) For the ./configure command line option, does
> --enable-integer-datetimes seem OK, or could someone suggest a better
> choice? --enable-integer-datetimes is a longer string than any of the
> other options, so a less wordy possibility may be better.

I'd suggest --enable-bigint-datetimes, or possibly
--enable-int8-datetimes, to make it clearer that 64-bit-int support
is needed.

A more interesting question is which way should be the default; might it
make sense to default to bigint datetimes on machines where it's
possible to do so?  Without performance info it's probably too soon
to decide, though.

> 2) Actually using integer date/time storage depends on whether 64-bit
> integers are really supported. So although they may be enabled, it may
> not be supported. Should ./configure error out at that point, or should
> things gracefully (silently?) configure to use the existing floating
> point implementation? See (3).

No strong feeling here, but I suspect Peter will say that it should
error out.

> 3) ./configure checks for several different styles of 64-bit integers to
> see what is actually supported. But it does not control whether an
> overall "yes we have some kind of 64-bit integer" flag gets defined. So
> detecting an inconsistancy in enabling 64-bit integer storage on
> machines without 64-bit integers seems to be out of the scope of
> ./configure. Correct?

No.  configure must define either HAVE_LONG_INT_64 or
HAVE_LONG_LONG_INT_64 to get the int8 support to work.  If neither gets
defined, you should conclude that bigint datetimes won't work.
        regards, tom lane

> I'd suggest --enable-bigint-datetimes, or possibly
> --enable-int8-datetimes, to make it clearer that 64-bit-int support
> is needed.

Hmm. The *feature* it is enabling is "consistant precision through the
range of allowed values". I'd rather move in the direction of
qualitative description, than toward the direction of explicit
underlying implementation.

> A more interesting question is which way should be the default; might it
> make sense to default to bigint datetimes on machines where it's
> possible to do so?  Without performance info it's probably too soon
> to decide, though.

Right. The default could be changed sometime later.

...
> No strong feeling here, but I suspect Peter will say that it should
> error out.

There is code in c.h which links the HAVE_xxx definitions to compiler
types, etc. But is *also* defines INT64_IS_BUSTED as a catchall for
having not found any int64 types at all. And it isn't until this point
that anyone knows for sure that there is not an int64 type. At least in
the current code, at least afaict. And at that point, we don't allow
things to "error out" in the sense of allowing "#error" or something
similar.

> No.  configure must define either HAVE_LONG_INT_64 or
> HAVE_LONG_LONG_INT_64 to get the int8 support to work.  If neither gets
> defined, you should conclude that bigint datetimes won't work.

Sure. The problem is in doing that in two different places for two
different reasons, where it *should* happen in one place (or at least at
similar stages of the process). The possibilities you have raised don't
have that happening so istm that we are still missing something. As you
point out, Peter will probably have a suggestion ;)
                    - Thomas

Thomas Lockhart writes:

> I've got patches to enable storage of date/time values as integers
> rather than as floating point numbers, as discussed earlier.

I'd like to know first what the overall plan for this feature is.  If it
is to make the date/time values "better" all around, i.e., you get exact
arithmetic and comparable range and precision, and the same or better
speed, then I'd vote for making it the default and offering the old
implementation as a (silent?) fallback.  If, on the other hand, it is a
space vs. time vs. whatever tradeoff then we'd really need to see the
numbers first to decide where to go with it.

The other day I offered the "rules of the game" for configure options, one
of which was that an option should not replace one behavior by another,
so that binary packagers can make neutral decisions about which options to
build with.  The last thing we'd want to happen is that every operating
system distribution comes with a different timestamp implementation.  That
would be quite a chaos.

-- 
Peter Eisentraut   peter_e@gmx.net

> > I've got patches to enable storage of date/time values as integers
> > rather than as floating point numbers, as discussed earlier.
> I'd like to know first what the overall plan for this feature is.

My feeling is that the int64 implementation will be "better". But I
*don't* know how many platforms support that data type, and I'm not yet
sure if there will be a measurable performance difference on (some?)
platforms.

I'd expect that we could form a consensus on the best default over the
next couple of months. In either case, the option should be selectable,
otherwise some of us would have trouble testing the feature set, right?

Did you catch the questions on dealing with HAVE_LONG_INT_64,
HAVE_LONG_LONG_INT_64, and INT64_IS_BUSTED? I'd like to be able to
enable/disable integer date/time storage in configure, so some notion of
"do I have some kind of 64 bit integer?" seems to be desirable in
configure itself.
                     - Thomas

Thomas Lockhart writes:

> Did you catch the questions on dealing with HAVE_LONG_INT_64,
> HAVE_LONG_LONG_INT_64, and INT64_IS_BUSTED? I'd like to be able to
> enable/disable integer date/time storage in configure, so some notion of
> "do I have some kind of 64 bit integer?" seems to be desirable in
> configure itself.

Is this what you want?

if test "$enable_integer_datetimes" = yes; then if test "$HAVE_LONG_LONG_INT64" != yes && test "$HAVE_LONG_INT64" !=
yes;then   AC_MSG_ERROR([integer datetimes not available due to lack of 64-bit integer type]) fi
 
fi

-- 
Peter Eisentraut   peter_e@gmx.net