On Tue, Nov 9, 2010 at 10:54 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Vick Khera <vivek@xxxxxxxxx> writes: >> On Tue, Nov 9, 2010 at 10:26 AM, Scott Ribe <scott_ribe@xxxxxxxxxxxxxxx> wrote: >>> Also, my understanding is that if you go way back on the PostgreSQL timeline to versions 6 and earliest 7.x, it was a little shaky. (I started with 7.3 or 7.4, and it has been rock solid.) > >> In those same times, mysql was also, um, other than rock solid. > > I don't have enough operational experience with mysql to speak to how > reliable it was back in the day. What it *did* have over postgres back > then was speed. It was a whole lot faster, particularly on the sort of > single-stream-of-simple-queries cases that people who don't know > databases are likely to set up as benchmarks. (mysql still beats us on > cases like that, though not by as much.) I think that drove quite a > few early adoption decisions, and now folks are locked in; the cost of > conversion outweighs the (perceived) benefits. Postgres 7.2 brought non blocking vacuum. Before that, you could pretty much write off any 24x7 duty applications -- dealing with dead tuples was just too much of a headache. The mysql of the time, 3.23, was fast but locky and utterly unsafe. It has been easier to run though until recently (8.4 really changed things). Postgres has been relatively disadvantaged in terms of administrative overhead which is a bigger deal than sql features, replication, performance, etc for high load website type cases. heap FSM, tunable autovacuum, checkpoint management, smarter/faster statistics collector, and more backup options may not be as sexy as replication etc but are very appealing features if you are running 50 database servers backing a monster web site. Dumping sys v ipc for mmap is a hypothetical improvement in that vein :-) (aiui, it is not possible though). merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
