En kategori av frågor med limit är snabbare och använder mindre datatrafik, eftersom det begärda antalet rader skickas vidare till plattformen istället för att tillämpas i efterhand (server-side filtering). Frågor behöver inte ändras; förbättringarna blir genast aktiva.
Mindre uppdrag; bättre prestanda
Datavolymen förbättras avsevärt genom att färre rader hämtas, och ofta är varaktigheten också avsevärt bättre jämfört med version 26.0. Antalet rader går med i uppdraget som plattformen får.
En relationsdatabas får filtret som en del av påståendet (beroende på plattform som limit, fetch first eller top (n)). En API får det som en del av begäran, till exempel som $top. De rader som inte behövs byggs inte upp av plattformen, skickas inte och läses inte.
På GLAccounts av Exact Online hämtar limit 3 per administration 4.670 byte på 297 ms, jämfört med 92.940 byte och 1.356 ms utan den begränsningen, och det följer ingen andra sida till skillnad från tidigare 4 API-anrop:
select *
from ExactOnlineREST..GLAccounts@eol
limit 3
På en PostgreSQL-tabell med 1,7 miljoner rader minskar också volymen motsvarande, och exekveringstiden minskar från 87 sekunder till 125 millisekunder:
select *
from tabel@postgresql
limit 3
Första intrycket av *Incremental tabellen av Exact Online
Att hämta ett intryck av en inkrementell tabell (*Incremental) genom att begära de första hundra eller tusen raderna går upp till tusen gånger snabbare. Detta är ett vanligt scenario vid första användningen, till exempel med Navigator i Power Query och Power BI.
Att bestämma den första raden av en inkrementell tabell såsom TransactionLinesIncremental är kostsamt: hela datasetet måste hämtas och uppdateras för det. Vid en limit på högst 2.500 rader hämtas raderna nu direkt från synkroniseringsändpunkten. Det kräver en anrop per administration för varje 1.000 begärda rader, och tar bara några sekunder, istället för att hela administrationen först ska hämtas.
På en TransactionLinesIncremental-tabell med 650 tusen rader, fördelade över 5 parter, minskar exekveringstiden från 867 till 2 sekunder om cacharna inte redan är laddade:
select *
from TransactionLinesIncremental@eol
limit 1000
När filtret finns kvar inom Invantive UniversalSQL
Om raderna behövs innan begränsningen kan tillämpas, tillämpar Invantive UniversalSQL begränsningen efter att raderna har kommit in. Detta händer bland annat vid sortering på en kolumn som plattformen inte kan sortera på, vid ett villkor som plattformen inte själv kan beräkna, och vid en datamängd som längre fram i frågan fortfarande ska kombineras.
Tillgänglighet
Den nya funktionaliteten finns tillgänglig från version 27.0.