X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 72696DB37B for ; Sun, 30 Oct 2005 13:44:56 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 76115-02 for ; Sun, 30 Oct 2005 17:44:53 +0000 (GMT) Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by svr1.postgresql.org (Postfix) with ESMTP id 9571EDA848 for ; Sun, 30 Oct 2005 13:44:53 -0400 (AST) Received: from trofast.ipv6.sesse.net ([2001:700:300:dc03:20e:cff:fe36:a766] helo=trofast.sesse.net) by cassarossa.samfundet.no with esmtp (Exim 4.50) id 1EWHEf-0002up-IJ; Sun, 30 Oct 2005 18:44:51 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1EWHEg-0005ul-00; Sun, 30 Oct 2005 18:44:50 +0100 Date: Sun, 30 Oct 2005 18:44:50 +0100 From: "Steinar H. Gunderson" To: Svenne Krap Cc: PgSQL Performance Subject: Re: multi-layered view join performance oddities Message-ID: <20051030174450.GA22399@uio.no> Mail-Followup-To: Svenne Krap , PgSQL Performance References: <4364FFD4.2020801@krap.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4364FFD4.2020801@krap.dk> X-Operating-System: Linux 2.6.14-rc5 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.009 required=5 tests=[AWL=0.009] X-Spam-Score: 0.009 X-Spam-Level: X-Archive-Number: 200510/462 X-Sequence-Number: 15230 On Sun, Oct 30, 2005 at 06:16:04PM +0100, Svenne Krap wrote: > Nested Loop (cost=223.09..338.61 rows=1 width=174) (actual time=20.213..721.361 rows=2250 loops=1) > Join Filter: (("outer".dataset_id = "inner".dataset_id) AND ("outer".nb_property_type_id = "inner".nb_property_type_id)) > -> Hash Join (cost=58.04..164.26 rows=1 width=150) (actual time=5.510..22.088 rows=2250 loops=1) There's horrible misestimation here. It expects one row and thus starts a nested loop, but gets 2250. No wonder it's slow :-) The misestimation can be traced all the way down here: > Hash Cond: ("outer".institut = "inner".id) > -> Hash Join (cost=56.88..163.00 rows=16 width=137) (actual time=5.473..19.165 rows=2250 loops=1) > Hash Cond: ("outer".dataset_id = "inner".id) > -> Hash Join (cost=55.48..160.95 rows=99 width=101) (actual time=5.412..16.264 rows=2250 loops=1) where the planner misestimates the selectivity of your join (it estimates 99 rows, and there are 2250). I've had problems joining with Append nodes in the past, and solved the problem by moving the UNION ALL a bit out, but I'm not sure if it's a very good general solution, or a solution to your problems here. If all else fails, you could "set enable_nestloop=false", but that is not a good idea in the long run, I'd guess -- it's much better to make sure the planner has good estimates and let it do the correct decisions from there. /* Steinar */ -- Homepage: http://www.sesse.net/