X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 55299528BB for ; Fri, 3 Jun 2005 20:28:39 -0300 (ADT) 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 97787-08 for ; Fri, 3 Jun 2005 23:28:31 +0000 (GMT) Received: from cmailm4.svr.pol.co.uk (cmailm4.svr.pol.co.uk [195.92.193.211]) by svr1.postgresql.org (Postfix) with ESMTP id 8D63F52816 for ; Fri, 3 Jun 2005 20:28:31 -0300 (ADT) Received: from modem-2569.leopard.dialup.pol.co.uk ([217.135.154.9] helo=192.168.0.102) by cmailm4.svr.pol.co.uk with esmtp (Exim 4.41) id 1DeLab-0000tq-Bc; Sat, 04 Jun 2005 00:28:33 +0100 Subject: Re: Query plan for very large number of joins From: Simon Riggs To: philb@vodafone.ie Cc: pgsql-performance@postgresql.org In-Reply-To: <189960.1117801361979.JavaMail.tomcat@iecsai19> References: <189960.1117801361979.JavaMail.tomcat@iecsai19> Content-Type: text/plain Organization: 2nd Quadrant Date: Sat, 04 Jun 2005 00:23:57 +0100 Message-Id: <1117841037.3844.1250.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.054 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200506/81 X-Sequence-Number: 12719 On Fri, 2005-06-03 at 13:22 +0100, philb@vodafone.ie wrote: > > >>> I am using PostgreSQL (7.4) with a schema that was generated > >>> automatically (using hibernate). The schema consists of about 650 > >>> relations. One particular query (also generated automatically) > >>> consists of left joining approximately 350 tables. > Despite being fairly restricted in scope, > the schema is highly denormalized hence the large number of tables. Do you mean normalized? Or do you mean you've pushed the superclass details down onto each of the leaf classes? I guess I'm interested in what type of modelling led you to have so many tables in the first place? Gotta say, never seen 350 table join before in a real app. Wouldn't it be possible to smooth out the model and end up with less tables? Or simply break things up somewhere slightly down from the root of the class hierarchy? Best Regards, Simon Riggs