Andres Freund <andres@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 ...
