Re: Is PostgreSQL an easy choice for a large CMS? - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Is PostgreSQL an easy choice for a large CMS?
Date
Msg-id 1146505319.22037.19.camel@state.g2switchworks.com
Whole thread Raw
In response to Re: Is PostgreSQL an easy choice for a large CMS?  (Philip Hallstrom <postgresql@philip.pjkh.com>)
Responses Re: Is PostgreSQL an easy choice for a large CMS?
List pgsql-general
On Mon, 2006-05-01 at 12:08, Philip Hallstrom wrote:
> > 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 was under the impression that they also created a lot of static text
for pages that are older than x number minutes or days, with updates to
those pages becoming further apart as the page for older.

> 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...

Yeah, table level locking doesn't really scale well.

pgsql-general by date:

Previous
From: Wes
Date:
Subject: Leading substrings - alternatives with 8.1.3?
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Leading substrings - alternatives with 8.1.3?