Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VawcK-0008O3-Vh for pgsql-performance@arkaria.postgresql.org; Mon, 28 Oct 2013 23:53:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VawcK-0001V9-Ea for pgsql-performance@arkaria.postgresql.org; Mon, 28 Oct 2013 23:53:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VawcJ-0001Tm-22 for pgsql-performance@postgresql.org; Mon, 28 Oct 2013 23:53:03 +0000 Received: from exprod5og119.obsmtp.com ([64.18.0.189]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VawcG-00046K-6e for pgsql-performance@postgresql.org; Mon, 28 Oct 2013 23:53:02 +0000 Received: from mail-ie0-f170.google.com ([209.85.223.170]) (using TLSv1) by exprod5ob119.postini.com ([64.18.4.12]) with SMTP ID DSNKUm742sSSsG7WcgfL2elVdTa+oJ8naXvE@postini.com; Mon, 28 Oct 2013 16:53:00 PDT Received: by mail-ie0-f170.google.com with SMTP id at1so13022063iec.29 for ; Mon, 28 Oct 2013 16:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enova.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JnIADKJdd0Cpxq2jtZPegmSMzhbYom6SkRzPsA2xX58=; b=E1z3PedcsY3qxRSVIrb3R3WSOMAV4BuDrQosvihqEt4xED92sBbXttgHGkhcoi8EMS yw/vSMGfi1Gi3zPiCU2dGXw3E+O2Zk97QN7S14AWbrr2kNvsN73yJnDthiVppaq5saP8 pBEO4l5Owu2DNLXdKS2zmoOSzju/+LRlCiuLE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JnIADKJdd0Cpxq2jtZPegmSMzhbYom6SkRzPsA2xX58=; b=bmyOzpl1A/NVdU4vrt/Dk/RCLa5TyzW9tedWNRbTIm/d2bm70s49g+CNXNF7Z/AfOE AQ4IzvBapvjXxdtx4cOy7GfQ6ya0ECtNHX45t3tHY9oaKssFrgeb/2JNyS/mQ6hqq8Gi HkmHpLFrIBWH85gRSVky5WRThNr46teJnUlSiZLlM3AFB1bloO1VuXSp6PUSXSHHC0Hk RQLByKvtTJ8cQewJ11eK/mDQp1QV3QFRpB4CKj/wvKXn/6Q//IH9dxpnvPAAeOEjWpY5 g2oBYkBYfJmOR4lTPu3+cXz8w3ajjKC8WqMyZjf77B4p1STRryAClGVjSWuW0iYX6Tm1 aMBw== X-Gm-Message-State: ALoCoQnOUyzcHUPatZoLdUKt+A1hx3kQn8w/4VK0ikQgPXYcfdmaFHEHOPMQDPj5NeRJtJBdO6L9MO+LF8of8LbB8bnkRWgNa9BhhxmFD2JkF24ONHLspL9XM6bSZDNqHal/IVMysyr1aSOxlkRXh6SbVe/H9SgOMBvtrlaEoystmoH3OHq2RyrYd18z8SX6YKhj06f6nJtE X-Received: by 10.42.63.194 with SMTP id d2mr14720797ici.10.1383004378124; Mon, 28 Oct 2013 16:52:58 -0700 (PDT) X-Received: by 10.42.63.194 with SMTP id d2mr14720787ici.10.1383004377945; Mon, 28 Oct 2013 16:52:57 -0700 (PDT) Received: from decina.local (rrcs-67-79-71-90.sw.biz.rr.com. [67.79.71.90]) by mx.google.com with ESMTPSA id x6sm1342957igb.3.2013.10.28.16.52.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Oct 2013 16:52:57 -0700 (PDT) Message-ID: <526EF8DF.8080705@enova.com> Date: Mon, 28 Oct 2013 18:53:03 -0500 From: Jim Nasby User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Tom Lane CC: "pgsql-performance@postgresql.org" Subject: Re: Problems with hash join over nested loop References: <526EDDF7.3090102@enova.com> <13775.1383002035@sss.pgh.pa.us> In-Reply-To: <13775.1383002035@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.0 (--) 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 10/28/13 6:13 PM, Tom Lane wrote: > Jim Nasby writes: >> I've been working on trying to normalize a table that's got a bunch of text fields. Normalizing the first 4 has been a non-issue. But when I try and normalize 2 additional fields a bunch of query plans go belly-up. > > Try increasing join_collapse_limit/from_collapse_limit. I'm a bit > confused by your description but I think maybe you've got more than 8 > relations in the subqueries. Hell, never thought about that. Bumping it up did the trick. Thanks! -- Jim Nasby, Lead Data Architect (512) 569-9461 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance