Re: Cached/global query plans, autopreparation

2018-03-02 21:51 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Andres Freund <andres(at)anarazel(dot)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
>
>