Una categoría de consultas con limit es más rápida y consume menos tráfico de datos, ya que la cantidad solicitada de filas se envía a la plataforma en lugar de aplicarse después (filtrado del lado del servidor). Las consultas no necesitan modificarse; las mejoras entran en efecto de inmediato.
Consulta más pequeña; mayor rendimiento
El volumen de datos mejora significativamente al obtener menos filas, y a menudo la duración es también significativamente mejor en comparación con la versión 26.0. La cantidad de filas se incluye en la consulta que recibe la plataforma.
Una base de datos relacional recibe el filtro como parte de la instrucción (dependiendo de la plataforma como limit, fetch first o top (n)). Una API lo recibe como parte de la solicitud, por ejemplo como $top. Las filas que se omiten de esta manera no son construidas, enviadas ni leídas por la plataforma.
En GLAccounts de Exact Online, limit 3 por administración recupera 4.670 bytes en 297 ms, frente a 92.940 bytes y 1.356 ms sin esa limitación, y no sigue una segunda página comparado con antes 4 llamadas API:
select *
from ExactOnlineREST..GLAccounts@eol
limit 3
En una tabla PostgreSQL con 1,7 millones de filas, el volumen también baja proporcionalmente, y el tiempo de ejecución disminuye de 87 segundos a 125 milisegundos:
select *
from tabla@postgresql
limit 3
Primera impresión de la tabla *Incremental de Exact Online
Solicitar una primera impresión de una tabla incremental (*Incremental) mediante la consulta de las primeras cientos o miles de filas es hasta miles de veces más rápido. Este es un escenario común en el uso inicial, por ejemplo con el Navegador en Power Query y Power BI.
Determinar la primera fila de una tabla incremental como TransactionLinesIncremental es costoso: se debe obtener y actualizar todo el conjunto de datos. Con un limit de un máximo de 2.500 filas, las filas se obtienen ahora directamente del punto final de sincronización. Esto requiere una llamada por administración por cada 1.000 filas solicitadas y demora unos segundos, en lugar de recuperar primero toda la administración.
En una tabla TransactionLinesIncremental con 650 mil filas, distribuidas entre 5 partes, la ejecución baja de 867 a 2 segundos si los cachés (si los cachés aún no están cargados):
select *
from TransactionLinesIncremental@eol
limit 1000
Cuando el filtro se mantiene dentro de Invantive UniversalSQL
Si las filas son necesarias antes de poder aplicar la limitación, Invantive UniversalSQL aplica la limitación después de que las filas estén disponibles. Esto ocurre, entre otros casos, cuando se ordena por una columna que la plataforma no puede ordenar, cuando hay una condición que la plataforma no puede calcular por sí misma, y cuando un conjunto de datos se va a combinar más adelante en la consulta.
Disponibilidad
La nueva funcionalidad está disponible a partir de la versión 27.0.