On Fri, 3 Feb 2006 15:15, Peter Machell wrote: > Let's just say that I prefer an engine that can do the same work with > 10s of megabytes of RAM *faster* than MSSQL can do using gigabytes of RAM.
That's what I meant when I said time has moved on in the database sector. MS SQL still uses extensively primitive cacheing a la disk cache while others have optimized their internal file system structures to minimize hard disk access. Disk cacheing doesn't scale, so MS SQL requires disproportionate huge amounts of RAM to achieve the same performance as others, and since RAM is always a potential source of data corruption and that type of cache management very processor intensive it also requires more processor power for the same task while being less fault proof than the competition. You may say that RAM is cheap nowadays, but then you might forget that all hardware architectures supported by MS nowadays are rather limited in the amount of physical RAM they can address. In any case, other applications sharing that resource might want a chunk too and might get slowed down needlessly by the overly greedy and wasteful MS SQL. But that's just boring technical details most users have no interest in. They rather pay big money for licenses and hardware so that they don't have to start thinking. Horst _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
