My experience is that the majority of the things considered
easier to do in MySQL are just done differently in Postgres
and hence makes Postgres look slightly harder to manage to
those used to MySQL (and vice versa, but I suspect there
are more people with MySQL experience trying out Postgres
than the other way around).
A few things comes to mind making MySQL somewhat easier though:
- it is extremely rare for an upgrade to require dump/restore
- you don't have to worry about running vacuum analyze regularly
The common dump/restore requirement with Postgres makes it
harder to manage an installation (especially with lots of
databases) since a software upgrade must be synchronized
with a database reload for all databases (*).
The need for vacuum makes Postgres work less well straight
out of the box, if you don't know about it your performance
will slowly go down the drain. (I don't remember how the
vacuum improvements in 7.3 change this, will a 7.3
installation work reasonably well without vacuum being run
at all e.g. in a scenario with lots of updates? (**))
_
Mats Lofkvist
mal@algonet.se
(*) A temporary fix to this could be to change the
installation to install under a versioned directory
(a la gcc) just making the lastest version the default
and maybe then change postmaster to start the correct
version of the server after checking the database?
Even if the latter part is left out, just having the
old versions still available by default would improve
things imho. And of course postmaster should refuse
to start with a version mismatch (at least unless
some override flag is used), but maybe this is
already the case?
(**) If not, the auto-vacuum I have seen discussed
will be even more welcome :-)
