Martijn van Oosterhout wrote: > Since it's currently all for collecting statistics on tables, why can't it > collect another type of statistic, like: > > - How often the estimator gets it wrong? > > At the end of an index scan, the executor could compare the number of rows > returned against what was estimated, and if it falls outside a certain > range, flag it. > > Also, the average ratio of rows coming out of a distinct node vs the number > going in. > > For a join clause, the amount of correlation between two columns (hard). > > etc > > Ideally, the planner could then use this info to make better plans. > Eventually, the whole system could become somewhat self-tuning. > > Does anyone see any problems with this?
[ Discussion moved to hackers.] I have thought that some type of feedback from the executor back into the optimizer would be a good feature. Not sure how to do it, but your idea makes sense. It certainly could update the table statistics after a sequential scan. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
