En kategori med spørringer med limit er raskere og bruker mindre datatrafikk, ettersom det ønskede antallet rader blir oversendt til plattformen i stedet for å bli brukt i etterkant (server-side filtrering). Spørringene trenger ikke å endres; forbedringene aktiveres umiddelbart.
Mindre oppgave; høyere ytelse
Datavolumet forbedres betydelig ved å hente færre rader, og ofte er ytelsen også vesentlig bedre sammenlignet med versjon 26.0. Antallet rader er inkludert som en del av oppgaven plattformen får.
En relasjonsdatabase får filteret som en del av setningen (avhengig av plattformen som limit, fetch first eller top (n)). En API får det som en del av forespørselen, for eksempel som $top. Radene som faller utenfor blir ikke opprettet av plattformen, ikke sendt og ikke lest.
På GLAccounts i Exact Online henter limit 3 per administrasjon 4.670 bytes på 297 ms, mot 92.940 bytes og 1.356 ms uten den begrensningen, og det følger ingen andre side mot tidligere 4 API-kall:
select *
from ExactOnlineREST..GLAccounts@eol
limit 3
På en PostgreSQL-tabell med 1,7 millioner rader reduseres også volumet tilsvarende, og kjøretiden synker fra 87 sekunder til 125 millisekunder:
select *
from tabel@postgresql
limit 3
Første inntrykk av *Incremental tabell i Exact Online
Å hente et inntrykk av en inkrementell tabell (*Incremental) ved å spørre de første hundre eller tusen radene blir opptil tusenvis av ganger raskere. Dette er et vanlig scenario ved første bruk, for eksempel med Navigator i Power Query og Power BI.
Å finne den første raden av en inkrementell tabell som TransactionLinesIncremental er kostbart: hele datasettet må hentes og oppdateres. Med en limit på maksimalt 2.500 rader hentes radene nå direkte fra synkroniseringsendepunktet. Det krever én anrop per 1.000 forespurte rader per administrasjon og tar noen få sekunder, i stedet for at hele administrasjonen først må hentes.
På en TransactionLinesIncremental-tabell med 650 tusen rader, fordelt på 5 partier, reduseres kjøretiden fra 867 til 2 sekunder dersom hurtigbufferet ikke er lastet:
select *
from TransactionLinesIncremental@eol
limit 1000
Når filteret forblir innenfor Invantive UniversalSQL
Er radene nødvendige før begrensningen kan brukes, anvender Invantive UniversalSQL begrensningen etter at radene er mottatt. Dette skjer blant annet ved sortering på en kolonne som plattformen ikke kan sortere på, ved en betingelse plattformen ikke kan beregne selv, og ved en datainnsamling som kombineres videre i spørringen.
Tilgjengelighet
Den nye funksjonaliteten er tilgjengelig fra versjon 27.0.