Thread: Explain not accurate

Hi there,

I am quite new to postgresql, and love the explain feature. It enables
us to predict which SQL queries needs to be optimized before we see any
problems. However, I've run into an issue where explain tells us a the
costs of a quiry are tremendous (105849017586), but the query actually
runs quite fast. Even "explain analyze" shows these costs.

This makes me wonder: can the estimates explain shows be dead wrong?

I can explain in more detail (including the query and output of explain)
if needed. I'm using 7.4 on Solaris 8.

Sincerely,

--
Richard van den Berg, CISSP

Trust Factory B.V.      | http://www.trust-factory.com/
Bazarstraat 44a         | Phone: +31 70 3620684
NL-2518AK The Hague     | Fax  : +31 70 3603009
The Netherlands         |

Visit us at Lotusphere 2004 http://www.trust-factory.com/lotusphere

On Fri, 9 Jan 2004, Richard van den Berg wrote:

> problems. However, I've run into an issue where explain tells us a the
> costs of a quiry are tremendous (105849017586), but the query actually
> runs quite fast. Even "explain analyze" shows these costs.

It would be helpful if you can show the query and the EXPLAIN ANALYZE of
the query (and not just EXPLAIN).

> This makes me wonder: can the estimates explain shows be dead wrong?

Of course they can. An estimation is just an estimation. If you have not
analyzed the database then it's most likely wrong. Dead wrong is not
common, but not impossible.

Run VACUUM ANALYZE and see if the estimate is better after that.

--
/Dennis Björklund

You need to regularly run 'analyze'.

Chris

Richard van den Berg wrote:
> Hi there,
>
> I am quite new to postgresql, and love the explain feature. It enables
> us to predict which SQL queries needs to be optimized before we see any
> problems. However, I've run into an issue where explain tells us a the
> costs of a quiry are tremendous (105849017586), but the query actually
> runs quite fast. Even "explain analyze" shows these costs.
>
> This makes me wonder: can the estimates explain shows be dead wrong?
>
> I can explain in more detail (including the query and output of explain)
> if needed. I'm using 7.4 on Solaris 8.
>
> Sincerely,
>

Richard van den Berg <richard.vandenberg@trust-factory.com> writes:

> Hi there,
>
> I am quite new to postgresql, and love the explain feature. It enables us to
> predict which SQL queries needs to be optimized before we see any problems.
> However, I've run into an issue where explain tells us a the costs of a quiry
> are tremendous (105849017586), but the query actually runs quite fast. Even
> "explain analyze" shows these costs.

Do you have any of the optimization parameters off, enable_seqscan perhaps?

enable_seqscan works by penalizing plans that use sequential plans, but there
are still lots of queries that cannot be done any other way. I'm not sure
whether the same holds for all the other parameters.

If your tables are all going to grow drastically then this may still indicate
a problem, probably a missing index. But if one of them is a reference table
that will never grow then perhaps the index will never be necessary.


Or perhaps you just need to run analyze. Send the "EXPLAIN ANALYZE" output for
the query for starters. You might also send the output of "SHOW ALL".

--
greg