George,

O.K. the following testing program:

CREATE CURSOR x1 (Test I, group I)
FOR nT = 1 TO 300000
	INSERT INTO x1 VALUES (nT, nT % 1000)
ENDFOR

SET ENGINEBEHAVIOR 70
nSec=SECONDS()
SELECT Group, Test FROM x1 GROUP BY x1.group INTO CURSOR y
WAIT WINDOW STR(SECONDS() - nSec, 6, 3)

SET ENGINEBEHAVIOR 80

nSec=SECONDS()
SELECT Group, MAX(Test) Test FROM x1 GROUP BY x1.group INTO CURSOR y
WAIT WINDOW STR(SECONDS() - nSec, 6, 3)

On my P4 2Ghz, it shows that the seconds query is about 10% (0.541 sec and 0.592 sec) slower than the first one. Measurable ? yes. Significant? I don´t think so
Is this a representive test ? No, because it´s a very simple query containing no joins and the data comes from memory (cursor) instead of a table stored on disk or a newwork drive.

When applying this same test where the data is stored on a network drive and is used by more than one user (so no read buffering occurs on the client), I found the following that the difference dropped to less than 5 percent on 100 Mbs full duplex network. When doing this same test on a 10 MB full duplex network, the difference where below 1 percent and almost not measurable anymore.

Given the first test on my 2Ghz machine, I see an overhead of the MAX() function of about 0.05 seconds per 300.000 selected records. This time is nothing compared to the additional time needed for doing joins or processing where clauses and processing the actual query. In the test I did also disregard the time need to open tables addressed in the Query.

WHAT THE HELL ARE WE TALKING ABOUT !?!!

Conclusion: in a production enviroment there is no significant overhead in using the MAX() function in stead of relying on the last physical row.

Walter,