Re: [PERFORM] Explain not accurate
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PERFORM] Explain not accurate
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, ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] Explain not accurate
Richard van den Berg [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
