On 31 December 2015 at 04:39, Evgeniy Shishkin <itparan...@gmail.com> wrote:

> > On 30 Dec 2015, at 10:16, David Rowley <david.row...@2ndquadrant.com>
> wrote:
> >
> > A number of ideas were suggested on the other thread about how we might
> go about solving this problem. In [3] Simon talked about perhaps enabling
> extra optimisations when the planner sees that the plan will cost more than
> some given threshold. That's perhaps an option, but may not work well for
> optimisations which must take place very early in planning, for example [4].
> > Another idea which came up was from Evgeniy [5], which was more of a
> request not to do it this way, but never-the-less, the idea was basically
> to add lots of GUCs to enable/disable each extra planner feature.
> >
> Well, my idea was to track planning/execution cost in something like
> pg_stat_statements.
> That way we can track actual time, not estimated cost like Simon proposed.
I like this idea also, but I do see the use for this as more of a guide
which could be used by the DBA to tweak some sort of planner_effort GUCs. I
don't think that the data of pg_stat_statements could be used by the
planner as this is an extension rather than core code.

 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Reply via email to