Hi, > 20 feilds or columns is really nothing. BUT That's dependant on the type > of data being inserted. 20 was an arbitary number :) > 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. That was the reason the original develop gave for having these massive rows! Admittedly it is easier to read but when each row also contains text/blob fields, they tend to grow rather big. Some users have been complaining the server seems to be getting sluggish so I'm trying to plan ahead and make changes before it becomes a real problem. > 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. It's an old server with all slots populated so adding memory is not an option. I thought of doing an image and porting it into a VM on a newer/faster machine. But then at the rate this client's usage growing, I foresee that as simply delaying the inevitable. > If speed is what your after why are you worried about VFS? > CentOS does support Raw Disk Access (no filesystem). To be honest, I don't really care about VFS since I didn't know it existed until I started looking up Linux file/disk caching :D So I assumed that was what PHP and DBMS like MySQL/Postgresql would be working through. It made sense since they wouldn't need to worry about what filesystem was really used.