Re: Cached/global query plans, autopreparation

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
Date: 2018-03-02 21:11:44
Message-ID: CAFj8pRDvzcTPQQEXdPcckMXi=q+Cx_VM7_S7QV301n9Noy2CVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
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