Re: Idea for the statistics collector - Mailing list pgsql-general

From Tom Lane
Subject Re: Idea for the statistics collector
Date
Msg-id 16739.1024634838@sss.pgh.pa.us
Whole thread Raw
In response to Idea for the statistics collector  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Idea for the statistics collector
List pgsql-general
Martijn van Oosterhout <kleptog@svana.org> writes:
> 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?
> [snip]
> Does anyone see any problems with this?

(1) forced overhead on *every* query.
(2) contention to update the same rows of pg_statistic (or wherever you
    plan to store this info).
(3) okay, so the estimate was wrong; exactly which of the many
    parameters that went into the estimate do you plan to twiddle?
    What if it's not the parameter values that are at fault, but the
    cost-model equations themselves?

Closed-loop feedback is a great thing when you understand the dynamics
of the system you intend to apply feedback control to.  When you don't,
it's a great way to shoot yourself in the foot.  Unfortunately I don't
think the PG optimizer falls in the first category at present.

            regards, tom lane

pgsql-general by date:

Previous
From: Peter Dimov
Date:
Subject: Re: URGENT: Performance tuning
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Idea for the statistics collector