On Tue, Nov 9, 2010 at 10:54 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vick Khera <vivek@khera.org> writes:
>> On Tue, Nov 9, 2010 at 10:26 AM, Scott Ribe <scott_ribe@killerbytes.com> wrote:
>>> Also, my understanding is that if you go way back on the PostgreSQL timeline to versions 6 and earliest 7.x, it was
alittle 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