Gordon McMillan wrote:
Worth repeating, because it highlights a fundamental aspect of MK's column-wise data storage model. You can open a datafile of any size, point at a view with 10s of thousands of "rows" of any complexity, and still do the above scan-on-open with no other overhead than one read of a few Kb off the disk. This is to efficient, that any other approach is a waste of effort in most cases.Why sort it? Scan on open for the maxid, and maintain that in memory. It's lower overhead, and doesn't interfere with whatever ordering the app might want to see or maintain.
Column-wise data storage means a scan over one property is f a s t.
It would be even faster if MK had C-coded loop aggregate functions such as "max", but hey - there need to be some goodies saved up for later :)
One last point on this. This sort of tight max-scan loop takes maximum advantage of CPU caches (even more so if coded in C). On modern CPU's, that equates to "warp drive".
-jcw
_______________________________________________
metakit mailing list - [EMAIL PROTECTED]
http://www.equi4.com/mailman/listinfo/metakit
