Uwe Just to be clear:

select TableName where Nr (or Id)

is faster than

select TableName

Uwe 
Moin Uwe,

ich kann diese Behauptung nicht bestätigen.
Als Test habe ich eine Datenbank aufgebaut, in der 500.000 Einträge mit jeweils einem Textfeld, gefüllt mit 10 zufälligen Worten liegen.

Um lokales Caching im Browser auszuschließen, wie auch weitere Netzwerk-Einflüsse, habe ich die Selects jeweils einzeln in ein do as transaction gekapselt. Für jedes Select wird die Laufzeit innerhalb des do as transaction ausgerechnet und ein neuer Eintrag als Log erstellt. 
Der Code sieht so aus:
 

for i in range(0, 1000) do
    do as transaction
        let startTime := now();
        select Data;
        let elapsedTime := number(now() - startTime);
        let myTime := (create 'Select Timing Results');
        myTime.('Time in ms' := elapsedTime);
        myTime.(Auswahl := 3)
    end
end

Wichtig ist hier, dass die Zeitdifferenz nur den Select betrachtet, nicht das create. Auch die For-Schleife darf nicht im do as transaction laufen, da sonst weitere serverseitige Optimierungen greifen, die das Ergebnis verfälschen würden.

Es wird verglichen 

select Data;

vs

select Data where Nr;

Die Ergebnisse sehen wie folgt aus:

select Data:

Durchschnitt: 598.51ms, Standardabweichung: 144,07ms

select Data where Nr:

Durchschnitt: 596.57ms, Standardabweichung: 183,29ms

Varianz: 0,2642 und damit statistisch nicht signifikant

Grafisch sehen die Laufzeiten in etwa so aus:

X Achse: Gruppen von je 10ms 

Y Achse: Anzahl der Durchläufe, die in die jeweilige Gruppe fallen.

Bitte nicht falsch verstehen. 

select X where Y ist die mächtigste Waffe um Performance zu optimieren.
Ein einfaches select X where Nr ist aber nicht ausreichend.

Die Vorteile von select where entstehen durch folgenden Punkte:
- select ohne where lädt im Browser immer alle Datensätze komplett herunter. Dadurch entstehen Netzwerk-Verzögerungen, da mit höherer Anzahl an Records in der Regel auch deutlich mehr Daten übermittelt werden. Select where lädt dagegen nur die Daten vom Server, die nach dem Filter übrig bleiben. Bei select X where Nr bleiben nach wie vor alle Daten übrig, da jeder Eintrag dem Filter entspricht.
- select where hat nach meinen Tests einige Optimierungen die auf dem Server ausgeführt werden, die im Client nicht zu Verfügung stehen. 
- Optimierungen mit do as transaction sind in Verbindung mit einem guten select where Filter doppelt effizient, da der Arbeitsspeicher des Servers nur die Daten halten muss, die dem Filter entsprechen. Bei einem "do as transaction select X[A = Bedingung] end" müssen alle Datensätze im Arbeitsspeicher gehalten werden. Das ist nicht sinnvoll. Es hilft hier auch nicht, wenn die selects zuvor auf Variablen geschrieben werden ohne ein select where zu nutzen.

Weitere Optimierungen kommen durch die Reihenfolge der Filterargumente. Diese sollten so aufgebaut werden:
Boolean, Numbers, Date/Time/alle Anderen, Text
Innerhalb eines Datentyps sollten die Filter so angeordnet werden, dass die vorderen Argumente die größte Anzahl Einträge herausfiltern. Also ein Boolean-Vergleich, der nur 3 von 1000 Einträgen herausfiltert sollte hinter einem Vergleich stehen, der 500 von 1000 Einträgen herausfiltert.