Where I work we use mysql for a fairly busy website, and I'd like to
eventually start transitioning to postgres if possible. The largest
obstacle is the lack of replication as a core feature. I'm well aware
of the history behind why it's not in core, and I saw a post a while
back saying it would be in 8.4. I'd like to say I think this is a
very good idea, and I know a number of shops personally that did not
go with postgres just for this reason.
So anyways our general setup is that we have one master replicating to
one slave. We use the slave for generating various leaderboard stats
for our games. Most of these get generated every 4 hours. If we
wanted to duplicate this on postgres I'm not sure which replication
option would work best. Last time I looked at slony you had to edit
configs for each table you wanted to replicate, and the whole setup
was more complex then it needed to be. If it's still like that, I
think we would lose more then we gain by moving to postgres. Once
setup, the replication needs to be free of daily administration other
then routine automated tasks. We add new tables/remove old ones
almost on a daily basis.
Now for one of the main things we don't like about mysql. You can't
add indexes without locking the whole table, which means you can't go
back and add indexes later on a production app without shutting down
the whole system. The effect his has had is that when we add new
features to our games that would normally require an additional
column, we have to add a new table since we can't add an index to the
old table. When you add indexes in postgres, how much of a
performance hit will the database be taking while adding the index?
I haven't worked on a postgres installation that's as busy as our
mysql installation is. We get roughly 3-4 million page views per day,
with each page view probably averaging 4-6 db queries. Probably 20%
of these are cached. In addition we have our slave which does far
fewer, but more complicated queries. Quite a few of our tables will
gain thousands of rows per day, some tens of thousands. Some of our
busiest tables have tens of millions of rows. We could start to
archive some of these.
Chris
