2018-03-02 21:51 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>:
> Andres Freund <and...@anarazel.de> writes:
> > On 2018-03-02 15:29:09 -0500, Bruce Momjian wrote:
> >> While I have heard people complain about how other databases cache
> >> prepare plans, I have heard few complaints about the Postgres approach,
> >> and I haven't even heard of people asking to control the documented
> "five
> >> or more" behavior.
>
> > This *constantly* is a problem.
>
> Yeah, I've certainly heard complaints about it. I do agree with
> Bruce's conclusion that we should try to improve that behavior;
> but it's not entirely clear how. (A user-frobbable knob isn't
> necessarily the best answer.)
>
Can be this problem reduced if we can count number of possible paths?
Maybe it can work for some simple queries, what is majority in pgbench.
When I migrate from Oracle, there was a issue slow planning of very complex
views - probably optimization on most common values can work well.
Still I have a idea about some optimization based not on searching the best
plan of one parameter vektor, but for searching the best plan for all
possible vectors - or best worst case plan.
I don't think so this issue is solvable without changing optimization
method.
Or don't lost time with probably useless work and move forward to dynamic
execution - for example - dynamic switch from nested loop, to hashjoin to
mergejoin ...
regards, tom lane
>
>
