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
