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 DC3D052B84 for ; Thu, 28 Jul 2005 15:14:01 -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 18749-03 for ; Thu, 28 Jul 2005 18:13:53 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 251F652AAB for ; Thu, 28 Jul 2005 15:13:52 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j6SIDpfF025700; Thu, 28 Jul 2005 14:13:51 -0400 (EDT) To: Chris Travers Cc: Gnanavel S , pgsql-performance@postgresql.org Subject: Re: Left joining against two empty tables makes a query In-reply-to: <42E90E19.3030702@travelamericas.com> References: <42E86A03.1070803@travelamericas.com> <42E90E19.3030702@travelamericas.com> Comments: In-reply-to Chris Travers message dated "Thu, 28 Jul 2005 09:55:53 -0700" Date: Thu, 28 Jul 2005 14:13:51 -0400 Message-ID: <25699.1122574431@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200507/443 X-Sequence-Number: 13684 Chris Travers writes: > Secondly, the project table has *never* had anything in it. So where > are these numbers coming from? The planner is designed to assume a certain minimum size (10 pages) when it sees that a table is of zero physical length. The reason for this is that there are lots of scenarios where a plan created just after a table is first created will continue to be used while the table is filled, and if we optimized on the assumption of zero size we would produce plans that seriously suck once the table gets big. Assuming a few thousand rows keeps us out of the worst problems of this type. (If we had an infrastructure for regenerating cached plans then we could fix this more directly, by replanning whenever the table size changes "too much". We don't yet but I hope there will be something by 8.2.) You might try going ahead and actually putting a row or two into projects; vacuuming that will change the state to where the planner will believe the small size. (If you aren't ever planning to have anything in projects, why have the table at all?) regards, tom lane