MySQL's acquisition was one of the factor, the client wants to keep everything on the opensource side as far as possible. On the technical side, all tables are using the InnoDB engine because myISAM doesn't support either. Also previously during development, it was discovered that on some particular application/function, MyISAM caused a heavy load that went away after switching to InnoDB. Also, as part of my idea was to subsequently put the tables on different disks for better improvement. Postgresql supports that while MySQL appears to require all the tables remain on the same filesystem. There were other considerations that was discussed internally previously but without digging up docs, off hand, these are the key factors I can recall that drove the decision to eventually replace MySQL with Postgresql. On 1/27/10, Chan Chung Hang Christopher <christopher.chan at bradbury.edu.hk> wrote: > >>> Ah, well #1 on his list then is to figure out what he is running! >> >> LOL, I know it sounds quite noobish, coming across like I've no idea >> what DBMS it is running on. The system currently runs on MySQL but >> part of my update requirement was to decouple the DBMS so that we can >> make an eventual switch to postgresql. >> >> Hence the solution cannot be dependent on some specific MySQL >> functionality. > > > mysql's isam tables have a reputation for surviving just about anything > and great builtin replication support... > > postgresql less so (I suspect due to fake fsync/fsyncdata in the days > before barriers) but maybe things have improved a lot nowadays. > > Why are you switching? > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >