Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id DF8979F95B0 for ; Fri, 9 Nov 2007 11:42:09 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 04300-01-3 for ; Fri, 9 Nov 2007 11:42:04 -0400 (AST) Received: from mail.laliluna.com (mail.laliluna.com [85.190.26.55]) by postgresql.org (Postfix) with ESMTP id EA8559F959D for ; Fri, 9 Nov 2007 11:42:03 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by mail.laliluna.com (Postfix) with ESMTP id 21C725F8070 for ; Fri, 9 Nov 2007 16:42:00 +0100 (CET) Received: from mail.laliluna.com ([85.190.26.55]) by localhost (asterix.laliluna.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd1LJ4Q8YvRh for ; Fri, 9 Nov 2007 16:42:00 +0100 (CET) Received: from [192.168.1.100] (p54B2CEA5.dip.t-dialin.net [84.178.206.165]) by mail.laliluna.com (Postfix) with ESMTP id DE1765F805C for ; Fri, 9 Nov 2007 16:41:59 +0100 (CET) Message-ID: <47347F9F.1070309@laliluna.de> Date: Fri, 09 Nov 2007 16:41:19 +0100 From: Sebastian Hennebrueder User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: PostgreSQL vs MySQL, and FreeBSD References: <47344D43.5090506@geri.cc.fer.hr> In-Reply-To: <47344D43.5090506@geri.cc.fer.hr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.031 tagged_above=0 required=5 tests=AWL=0.030, BAYES_50=0.001 X-Spam-Level: X-Archive-Number: 200711/135 X-Sequence-Number: 27550 > > Among other things (FreeBSD advocacy, mostly :) ), it contains a direct > comparison between MySQL and PostgreSQL on various platforms, with > PostgreSQL winning! > Hello, If the queries are complex, this is understable. I had a performance review of a Hibernate project (Java Object Relation Mapping) using MySQL. ORM produces easily "complex" queries with joins and subqueries. MySQL uses nested loops for subqueries which lead to performance issues with growing database size. They state in their documentation that for version 5.2 there are improvements planned regarding this kind of query. Best Regards Sebastian