Bass said:Sven Groot said:*snip*
The same arguments have been made in the past regarding cooperative vs preemptive multitasking. I assume you know who won in the end. The thing about any engineering project is there is limited resources. If you choose to optimize one part of your DB (file I/O), you probably are missing out somewhere else (eg: CPU cache). As I said before, the CPU cache is not programmable. So if you don't design your data structures with the CPU cache in mind, you are losing a ridiculously important optimization.
Another thing you conveniently leave out if that kernel developer and database developer many times work for the same company. Eg: Oracle and IBM are both Linux kernel developers (both interestingly have contributed file systems to the Linux kernel). There is contributions to the Linux kernel that were specifically designed around making databases faster. Sometimes this means tweaking the characteristics of the I/O scheduler and filesystem to improve their database performance, and not the other way around.
Anyway what is interesting about DB performance is depending on what DB vendor you ask, their DB is the fastest. So you can argue about DB performence all day and what approach is better, but MySQL/Oracle/DB2/SQLServer/SQLite are all the fastest DB in existence anyway.
The same arguments have been made in the past regardless cooperative vs preemptive multitasking.
Not really... If your claim is:
OS file handling -> Generic (good)
DBMS "file" handling -> Specific (unnecessary)
then Preemptive vs. Cooperative doesn't fall on the same scale. Pre-emptive vs Cooperative fall more on hardware vs software. And I believe you know which is better.
Look, DBMSes DO have their own internal "file" / page / disk memory management... That's fact. Why? Because that code is more specific to their domain. DBMS loves contiguous blocks of memory... whereas, HDs have 1 to 2 Dimensions (spiral platters) to their storage.
PS. C9, fix the GD posting errors