So far the dump-and-restore method of upgrading postgres has not ever been a problem for me, but I can see how it could be a drag. MySQL 3.23 to 4.0 was a cinch on a large production site I run; it would have taken a few minutes of downtime to dump out the same tables in PostgreSQL and then read them back in.
Personally I find that subselects, foreign keys, views, and native ltree support are very useful in application development, so I prefer Postgres. However for a dedicated mailserver DB, MySQL would be better, just like it is for running ACID or other data collection backends. Using the right tool for the job is very important. I tore the holy hell out of dbmail in order to make it work on rockclimbing.com (we have about 1000 email users) but now it works like a charm and I'd never go back to anything else. My only problem is that Squirrelmail will not let users create folders. I believe this has been discussed on the mailing list, but if anyone remembers the answer offhand, that could save me some searching. Thanks in advance. --tim Quoth Matthew T. O'Connor: > Not true, postgres never suffered that limitation since it always has > (and still does) split files at the 1GB mark. So postgres can have > tables well in excess of 2GB even on kernels that do not support large > files. > > As for the mysql test tools, I know postgres used to have a problem > running the crashme test because crashme would crash before it reached > some of pg limits. Off hand, I can't remember which ones though. IMHO > one of the biggest advantages mysql has over pg is the upgrade process > which can be very ugly for postgres. > > On Sat, 2003-03-29 at 13:50, Curtis Maurand wrote: > > What size barrier? MySQL's size limit was Linux kernel limitation in the > > size of a file (2 GB). PostgreSQL suffered from the same limitation. > > That restriction went away with the 2.4 kernel. The limit is 2^32 blocks. > > If you're using 2K or 4K blocks, that's a pretty big file > > (4096 X 2^32 = 17,592,186,044,416) or 17 Terabytes. > > MySQL's limit is smaller than that. In fact, according to the folks at > > MySQL, it scales to very large files better than Oracle does. MySQL has > > made major changes when going to 4.0. In fact, if you install it, you > > need to recomile anything that uses shared libraries to access it. > > > > However, MySQL makes their benchmarking software availabel on their > > website and you can do your own comparison. > > > > see http://www.eweek.com/article2/0,3959,293,00.asp > > http://www.innodb.com/bench.html > > > > Curtis > > > > On Sat, 29 Mar 2003, lou wrote: > > > > > In some email I received from Jan PavlÃk <[EMAIL PROTECTED]> on Fri, 28 > > > Mar 2003 > > > 00:29:01 +0100, wrote: > > > > > > > No flame, and read :)) > > > > > > > > http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html > > > > http://www.mysql.com/doc/en/MySQL-PostgreSQL_benchmarks.html > > > > http://www.mysql.com/information/benchmarks.html > > > > > > > > > If I were you I`ll try a more unbiased opinion, since half of this stuff > > > is not proven, > > > considering the different concepts of mysql and postgresql, there are > > > certain differences, > > > but definitely these links wont clear the mist. > > > or mysql. somehow they forgot to mention the db size barrier in there, > > > pointer size blah > > > blah.. and the 16 years of pgsql development.. > > > Considering the fact that there is no such thing as unbiased comparison. > > > > > > actually > > > > > > best see for yourself. > > > http://www.google.com/search?q=postgres+vs+mysql&btnG=Google+Search > > > > > > > > > > > > > > > cheers > > > > > > > > > > > > > > _______________________________________________ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail -- "It's just a job. Grass grows, birds fly, waves pound the sand. I just beat people up." --Muhammad Ali
