Hello Lisa,

thanks for your feedback.

I have the same behaviour: SYSTIMESTAMP limited to 6 "F", although the database can handle more.
For example:

SQL> SELECT systimestamp def
  2    , systimestamp(9) explicit_9
  3    , systimestamp + NUMTODSINTERVAL( 0.123456789, 'SECOND' ) add_nanosec
  4    , TO_TIMESTAMP( '13-01-2025 20:30:40.987654321', 'DD-MM-YYYY HH24:MI:SS.FF' ) built
  5    FROM dual;
DEF                                    EXPLICIT_9                             ADD_NANOSEC                            BUILT                          
-------------------------------------- -------------------------------------- -------------------------------------- -------------------------------
16-JUL-25 10.11.30.474365000 AM +02:00 16-JUL-25 10.11.30.474365000 AM +02:00 16-JUL-25 10.11.30.597821789 AM +02:00 13-JAN-25 08.30.40.987654321 PM

So I suppose that the call to OS layer routines to feed SYSTIMESTAMP is limited to 6 F, but for example you might take advantage of more digits in a SQL Loader session with the timestamps wrtten as strings of chars. So we might say that Oracle "is not the guilty" here.

As I wrote: maybe it is not important if sometimes 2 or more rows are inserted within the same millionth of a second, but you have to forget about a unique index on the column (hence my suggestion to order with the rowid added despite Gerrit's remark). If it is important, maybe you work at the CERN ;-)

Your post gave me the opportunity to look at those very tiny time intervals, and there are really people needing them, even more detailed that nanoseconds (9F), have a look at the White_Rabbit_Project wow, amazing… There are more nanoseconds in one second than seconds in 30 years… And what about picoseconds :-)

Thanks and best regards,

Bruno.