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 pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026