|From:||Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, Shay Rojansky <roji(at)roji(dot)org>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Cached/global query plans, autopreparation|
|Views:||Raw Message | Whole Thread | Download mbox|
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
> >> 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
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
regards, tom lane
|Next Message||Pavel Stehule||2018-03-02 21:30:43||Re: Re: [HACKERS] plpgsql - additional extra checks|
|Previous Message||Tomas Vondra||2018-03-02 21:06:32||Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions|