On Sun, 2006-04-30 at 14:32, Tony Lausin wrote:
[ rotfl... ] MySQL will fall over under any heavy concurrent-write
scenario. It's conceivable that PG won't do what you need either,
but if not I'm afraid you're going to be forced into Oracle or one
of the other serious-money DBs.
regards, tom lane
Hi Tom,
That's a scary idea - being forced into Oracle or Sybase. Isn't
Slashdot.org still running strongly off of MySQL?
Depends on how you define strongly. Slashdot has a LOT of code in place
to cache the content so it never has to hit the database directly.
Basically, every X seconds, the data creating the site is ripped outta
the database and produced as static content so that the writes and reads
don't clobber each other. And it still takes a pretty big and fast
machine to handle the load.
I think slashdot uses memcache...
http://www.danga.com/memcached/users.bml
I would also read this about mysql's table locking:
http://dev.mysql.com/doc/refman/4.1/en/table-locking.html
Specifically, regarding myisam tables:
"Table locking enables many threads to read from a table at the same time,
but if a thread wants to write to a table, it must first get exclusive
access. During the update, all other threads that want to access this
particular table must wait until the update is done."
It doesn't take very many writes before this *really* becomes a problem.
We're implementing memcache at work to help with this issue...
-philip
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
