No hay inconvenientes, utilice la marca de tiempo (9) si tiene sentido.
La marca de tiempo (9) y la marca de tiempo (1) utilizan la misma cantidad de espacio, y su rendimiento es idéntico. Solo pude encontrar un caso en el que hubo una diferencia de rendimiento, y en ese caso la marca de tiempo (9) fue en realidad más rápida que la marca de tiempo (1).
(Les ahorraré las muchas líneas de código aburrida insertar en marca de tiempo (1) y la marca de tiempo (9) y la comparación de diferentes columnas operaciones con ellos.)
Esto demuestra que utilizan la misma cantidad de el espacio (la inserción de muchos valores y comparando dba_segments):
--Create tables with timestamps and populate them with the same data (with different precision)
--Set initial and next to a low value so we can closely check the segment size)
create table timestamp1 (t1 timestamp(1), t2 timestamp(1), t3 timestamp(1), t4 timestamp(1), t5 timestamp(1))
storage(initial 65536 next 65536);
insert into timestamp1
select current_timestamp(1), current_timestamp(1), current_timestamp(1), current_timestamp(1), current_timestamp(1)
from dual connect by level <= 100000;
create table timestamp9 (t1 timestamp(9), t2 timestamp(9), t3 timestamp(9), t4 timestamp(9), t5 timestamp(9))
storage(initial 65536 next 65536);
insert into timestamp9
select current_timestamp(9), current_timestamp(9), current_timestamp(9), current_timestamp(9), current_timestamp(9)
from dual connect by level <= 100000;
--Segment size is identical
select segment_name, bytes from dba_segments where segment_name in ('TIMESTAMP1', 'TIMESTAMP9');
--SEGMENT_NAME BYTES
--TIMESTAMP1 8388608
--TIMESTAMP9 8388608
Esto es donde marca de tiempo (9) es más rápido, cuando se utiliza current_timestamp, que es probable que necesite usar en algún momento de generar los datos. Pero solo estamos hablando de la diferencia entre aproximadamente 0.175 y 0.25 segundos en mi escritorio lento para generar 100K marcas de tiempo. No estoy seguro de por qué la marca de tiempo (9) es más rápida, tal vez las marcas de tiempo siempre se generan como marcas de tiempo (9) y luego se redondean a otras precisiones.
--current_timestamp(9) is slightly faster than current_timestamp(1)
select count(*) from
(
select *
from dual
--where current_timestamp(9) = current_timestamp(9)
where current_timestamp(1) = current_timestamp(1)
connect by level <= 100000
);
EDITAR: La diferencia de rendimiento existe en 10g pero no en 11g.
¿En qué se diferencia TIMESTAMP (1) exactamente de TIMESTAMP (9) desde la perspectiva del rendimiento? Las segundas fracciones no se almacenan como un entero de todos modos, por lo que no debería afectar a la CPU en absoluto en las búsquedas, por ejemplo. ¿Estás seguro de que TIMESTAMP (1) ocupa menos memoria internamente que TIMESTAMP (9)? – Leonid
¡Acaba de llegar al punto! SQL es declarativo, no tiene ninguna garantía de que TIMESTAMP (1) sea más pequeño que TIMESTAMP (9). Por ejemplo, Oracle para la plataforma de 64 bits puede decidir almacenar todas las marcas de tiempo, sin importar su elección, como enteros de 64 bits sin decírselo. Pero si especifica TIMESTAMP (9), Oracle le garantiza que nunca perderá precisión. Acerca del rendimiento, repito, podría notar una pérdida de rendimiento solo en ** cargas muy pesadas **, lo que podría ser improbable o no según su aplicación –
Mi pregunta es de dónde viene ** la pérdida de rendimiento ** en caso de indicación de la hora. si Oracle usa enteros para almacenar fracciones de segundo? TIMESSTAMP aquí en cuestión es de tipo Oracle y no tiene nada que ver con SQL. – Leonid