On Mon, 2010-01-25 at 01:09 +0800, Noob Centos Admin wrote: > e.g. the table may currently have rows with 20 fields and total > 1KB/row, but very often say only 5/20 fields are used in actual > processing. Reading x rows from this table may access x inodes which > would not fit into the cache/memory. 20 feilds or columns is really nothing. BUT That's dependant on the type of data being inserted. > However if now I break the table into two parts with those 5 fields > into a smaller table, there would be a speed increase since the > reading the same x rows from this table would only access 1/x inodes. > Further more, these would more likely fit into the disk/memory cache > for even faster access. Ok so break the one table down create 2 or more, then you will have "Joins" & clustered indexes thus slowing you down more possibly. That is greatly dependant on your select, delete, and update scripts. > Or would I simply be duplicating what the DBMS's index files would > already be doing and therefore see no improvement? Possibly very correct, but Nate is very correct on how you are accessing the DB ie direct i/o also. Your fastest access come in optimized SPROCS and Triggers and TSQL. Slam enough memory into the server and load it in memory. If speed is what your after why are you worried about VFS? CentOS does support Raw Disk Access (no filesystem). John