Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TjHyF-00062D-IE for pgsql-performance@arkaria.postgresql.org; Thu, 13 Dec 2012 23:13:39 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TjHyF-0005eq-33 for pgsql-performance@arkaria.postgresql.org; Thu, 13 Dec 2012 23:13:39 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TjHyE-0005el-66 for pgsql-performance@postgresql.org; Thu, 13 Dec 2012 23:13:38 +0000 Received: from mail-lb0-f174.google.com ([209.85.217.174]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TjHy9-0000Bz-2y for pgsql-performance@postgresql.org; Thu, 13 Dec 2012 23:13:37 +0000 Received: by mail-lb0-f174.google.com with SMTP id gi11so2283701lbb.19 for ; Thu, 13 Dec 2012 15:13:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=D4Bk2CAGbnKFGtkNgj/l228ioABdbORkoyzth1LzJtw=; b=c19VRftTtovQ3MDMeivHwzMacg8j0EJ9zO8STarDiRMLdGjMQ44B8lShsgQalMHYLx eyg5351dYjRYSMOHE0JPijTX3qYCTtwjjswYN2uWvFAx2JY2Sdb+yVFh2futXUxW1q26 C3m+nLV5rwJtXnLm1nupVzCZuA+9PKT+HH/Q+qpO2QFm/aRNYSWidhDZufkcrPLSGYgQ mRCw1O1L9zDTqLgD/L/2THOssncIuA5wFnnPnOge+6f1sw0ZqhYw4y+Hp7p7JLWHOoMR A2bYFEdkDxqscgCwl7cKWPYL/t1sUSK3/IBouMDXats8RMd1fErY3XEv81T9Ysq7PqxM xteA== Received: by 10.152.111.41 with SMTP id if9mr797116lab.23.1355440411550; Thu, 13 Dec 2012 15:13:31 -0800 (PST) Received: from [192.168.20.5] ([176.195.200.36]) by mx.google.com with ESMTPS id v7sm1230483lbj.13.2012.12.13.15.13.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 15:13:31 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Why does the number of rows are different in actual and estimated. From: Evgeny Shishkin In-Reply-To: <50CA6036.6000107@dunslane.net> Date: Fri, 14 Dec 2012 03:13:29 +0400 Cc: Claudio Freire , AI Rumman , postgres performance list Content-Transfer-Encoding: quoted-printable Message-Id: References: <50CA586A.30008@dunslane.net> <50CA6036.6000107@dunslane.net> To: Andrew Dunstan X-Mailer: Apple Mail (2.1499) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Dec 14, 2012, at 3:09 AM, Andrew Dunstan wrote: >=20 > On 12/13/2012 05:42 PM, Claudio Freire wrote: >> And it looks like it all may be starting to go south here: >>> -> Hash Join (cost=3D9337.97..= 18115.71 rows=3D34489 width=3D244) (actual time=3D418.054..1156.453 rows=3D= 205420 loops=3D1) >>> Hash Cond: (customerdetail= s.customerid =3D entity.id) >=20 >=20 > Well, it looks like it's choosing a join order that's quite a bit differe= nt from the way the query is expressed, so the OP might need to play around= with forcing the join order some. >=20 >=20 OP joins 8 tables, and i suppose join collapse limit is set to default 8. I= thought postgresql's optimiser is not mysql's. > cheers >=20 > andrew >=20 >=20 > --=20 > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance --=20 Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance