Re: Spotting planner errors (was Re: [PERFORM] Query planner is using
Tom Lane wrote: Richard Huxton writes: Tom - does the planner/executor know it's got row estimates wrong? That is, if I'm not running an EXPLAIN ANALYSE is there a point at which we could log "planner estimate for X out by factor of Y"? Not at the moment, but you could certainly imagine changing the executor to count rows even without EXPLAIN ANALYZE, and then complain during plan shutdown. Not sure how helpful that would be; there would be a lot of noise from common cases such as executing underneath a LIMIT node. Hmm - thinking about it you'd probably want to record it similarly to stats too. It's the fact that the planner *repeatedly* gets an estimate wrong that's of interest. Would it be prohibitive to total actions taken - to act as raw data for random_page_cost / cpu_xxx_cost? If you could get a ratio of estimated vs actual time vs the various page-fetches/index-fetches etc. we could actually plug some meaningful numbers in. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Spotting planner errors (was Re: [PERFORM] Query planner is using wrong index.)
Richard Huxton writes: > Tom - does the planner/executor know it's got row estimates wrong? That > is, if I'm not running an EXPLAIN ANALYSE is there a point at which we > could log "planner estimate for X out by factor of Y"? Not at the moment, but you could certainly imagine changing the executor to count rows even without EXPLAIN ANALYZE, and then complain during plan shutdown. Not sure how helpful that would be; there would be a lot of noise from common cases such as executing underneath a LIMIT node. regards, tom lane ---(end of broadcast)--- TIP 1: 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
