Een categorie van queries met limit is sneller en verbruikt minder dataverkeer, doordat het gevraagde aantal rijen wordt meegegeven aan het platform in plaats van pas achteraf toegepast te worden (server-side filtering). Queries hoeven niet aangepast te worden; de verbeteringen worden meteen actief.
Kleinere opdracht; hogere prestaties
Het datavolume wordt in grote mate verbeterd door minder rijen op te halen, en vaak is de duur ook significant beter vergeleken met release 26.0. Het aantal rijen gaat mee in de opdracht die het platform krijgt.
Een relationele database krijgt het filter als onderdeel van het statement (afhankelijk van het platform als limit, fetch first of top (n)). Een API krijgt het als onderdeel van het verzoek, bijvoorbeeld als $top. De rijen die daarmee wegvallen worden door het platform niet opgebouwd, niet verstuurd en niet gelezen.
Op GLAccounts van Exact Online haalt limit 3 per administratie 4.670 bytes op in 297 ms, tegen 92.940 bytes en 1.356 ms zonder die beperking, en er volgt geen tweede pagina tegen voorheen 4 API-calls:
select *
from ExactOnlineREST..GLAccounts@eol
limit 3
Op een PostgreSQL-tabel met 1,7 miljoen rijen daalt het volume ook navenant, en daalt ook de uitvoeringsduur van 87 seconden naar 125 milliseconden:
select *
from tabel@postgresql
limit 3
Eerste indruk van *Incremental tabel van Exact Online
Het opvragen van een indruk van een incremente tabel (*Incremental) door de eerste paar honderd of duizend rijen op te vraag wordt tot duizenden keren sneller. Dit is een veel voorkomend scenario bij het eerste gebruik, bijvoorbeeld met de Navigator in Power Query en Power BI.
Het bepalen van de eerste rij van een incrementele tabel zoals TransactionLinesIncremental is duur: de hele dataset moet daarvoor opgehaald en bijgewerkt worden. Bij een limit van maximaal 2.500 rijen worden de rijen nu rechtstreeks van het synchronisatie-eindpunt gehaald. Dat kost per administratie één aanroep per 1.000 gevraagde rijen en duurt enkele seconden, in plaats van dat de volledige administratie eerst wordt opgehaald.
Op een TransactionLinesIncremental-tabel met 650 duizend rijen, verdeeld over 5 parties, daalt de uitvoering van 867 naar 2 seconden als de caches (als de caches nog niet geladen zijn):
select *
from TransactionLinesIncremental@eol
limit 1000
Wanneer het filter binnen Invantive UniversalSQL blijft
Zijn de rijen nodig voordat de beperking toegepast kan worden, dan past Invantive UniversalSQL de beperking toe nadat de rijen binnen zijn. Dat gebeurt onder meer bij sorteren op een kolom waarop het platform niet kan sorteren, bij een voorwaarde die het platform niet zelf kan uitrekenen, en bij een gegevensverzameling die verderop in de query nog gecombineerd wordt.
Beschikbaarheid
De nieuwe functionaliteit is beschikbaar vanaf release 27.0.