Re: Temp table's effect on performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Robert James <srobertjames(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Temp table's effect on performance
Date: 2013-01-18 19:06:34
Message-ID: 11918.1358535994@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Fri, Jan 18, 2013 at 9:29 AM, Robert James <srobertjames(at)gmail(dot)com> wrote:
>> In other words: Since my query is 100% identical algebraicly to not
>> using a temp table, why is it so much faster? Why can't the planner
>> work in the exact same order?

> Unless you are doing ANALYZE on your temp table, then the planner has
> to make some guesses about the size and selectivity and correlations
> involved. Those guesses probably just got lucky at being better in
> this particular case than the real statistics.

Whether you've done ANALYZE or not, the planner can see the physical
size of the temp table, which allows it to make a rowcount estimate
based on a guess as to the average row width (which it can make, in
a pretty squishy way, given only the column datatypes). Now an
estimate gotten that way can be pretty far off, but it might still
be much better than what we can come up with for a sub-select (view).
Of course if you *have* done an ANALYZE on the temp table then the
planner is far better informed than when considering a view.

Whether that's the explanation is of course impossible to know from
the given (lack of) information.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Robert James 2013-01-18 19:51:00 Re: Temp table's effect on performance
Previous Message Jeff Janes 2013-01-18 18:43:18 Re: Temp table's effect on performance