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 3932E52968 for ; Fri, 29 Jul 2005 02:23:21 -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 31920-10 for ; Fri, 29 Jul 2005 05:23:17 +0000 (GMT) Received: from mail.travelamericas.com (unknown [206.130.134.147]) by svr1.postgresql.org (Postfix) with SMTP id 6C191528D2 for ; Fri, 29 Jul 2005 02:23:16 -0300 (ADT) Received: (qmail 12915 invoked from network); 29 Jul 2005 05:23:16 -0000 Received: from unknown (HELO ?10.0.0.253?) (10.0.0.253) by verkiel.travelamericas.com with SMTP; 29 Jul 2005 05:23:16 -0000 Message-ID: <42E9BD43.6060203@travelamericas.com> Date: Thu, 28 Jul 2005 22:23:15 -0700 From: Chris Travers User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gnanavel S Cc: Chris Travers , pgsql-performance@postgresql.org Subject: Re: Left joining against two empty tables makes a query References: <42E86A03.1070803@travelamericas.com> <42E90E19.3030702@travelamericas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.037 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200507/462 X-Sequence-Number: 13703 > > Secondly, the project table has *never* had anything in it. So where > are these numbers coming from? > > > pg_statistics I very much doubt that. I was unable to locate any rows in pg_statistic where the pg_class.oid for either table matched any row's starelid. Tom's argument that this is behavior by design makes sense. I assumed that something like that had to be going on, otherwise there would be nowhere for the numbers to come from. I.e. if there never were any rows in the table, then if pg_statistic is showing 1060 rows, we have bigger problems than a bad query plan. I hope however that eventually tables which are truly empty can be treated intelligently sometime in the future in Left Joins. Otherwise this limits the usefulness of out of the box solutions which may have functionality that we don't use. Such solutions can then kill the database performance quite easily. Chris Travers Metatron Technology Consulting