Re: Cached/global query plans, autopreparation
| От | Pavel Stehule |
|---|---|
| Тема | Re: Cached/global query plans, autopreparation |
| Дата | |
| Msg-id | CAFj8pRDvzcTPQQEXdPcckMXi=q+Cx_VM7_S7QV301n9Noy2CVw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Cached/global query plans, autopreparation (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
2018-03-02 21:51 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
Can be this problem reduced if we can count number of possible paths?
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.)
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
В списке pgsql-hackers по дате отправления: