Re: Left joining against two empty tables makes a query

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Chris Travers <chris(at)travelamericas(dot)com>
Cc: Gnanavel S <s(dot)gnanavel(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Left joining against two empty tables makes a query
Date: 2005-07-28 18:13:51
Message-ID: 25699.1122574431@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Chris Travers <chris(at)travelamericas(dot)com> 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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2005-07-28 18:19:28 Re: Unable to explain DB error
Previous Message Chris Hoover 2005-07-28 17:34:54 Re: Fwd: Help with view performance problem