In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Robert Treat) wrote:
> On Thursday 14 September 2006 12:19, Joshua D. Drake wrote: > > Arturo Perez wrote: > > > Hi all, > > > > > > Any response to this: > > > http://www.internetnews.com/dev-news/article.php/3631831 > > > > > Well first, your subject line is very incendiary and not necessary... I Well, sorry about that. The article, as written, made it sound like he said, "First, dump PostgreSQL to increase your performance then..." > > That said, in case anyone needs it, here is a benchmark showing postgresql > scalability vs mysql. interestingly enough it isnt really a database > benchmark, whether this adds or detracts from it's creditability is up to > you... http://tweakers.net/reviews/638/4 That's scalability, not speed. Don't know that the PHP/MySQL crowd have ever crowed about anything except speed. For those not knowing the difference, scalability is "we can handle 5000 concurrent transactions with an average response time of 10ms" while speed is "we can make this transaction complete in 10ms." The difference being that something fast may fall over if too many transactions occur within too small a window (deadlocking, thread synchronization overhead, table/row locking, etc) so that at 5000 concurrent transactions the speed may be reduced to significantly (as shown in the tweakers.net pages). > > > > However, he does carry some umpf in certain circles. Perhaps we should > > prove him wrong? > > > > I'd like to see you do that... here are the slides from his recent talk > showing why he came up with the statements he made > (http://talks.php.net/show/oscon06/1). Please post the info > when you get comparable performance running from PostgreSQL... That's what I'd really like to know. Honestly, how does one make pgSQL go really really fast on a vanilla machine that one is likely to encounter at a hosting facility? As a pgSQL enthusiast, I want to see all the things needed to get pgSQL to the 1500 tps level. Unfortunately, we don't know anything about the database requirements other than the one query shown in the source examples. I'll have to look at the system I recently converted from MySQL to PostgreSQL and see what I can find... -arturo ---------------------------(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
