On Mon, Sep 3, 2018 at 11:42:31AM -0700, Andres Freund wrote:
> On September 3, 2018 11:33:35 AM PDT, Bruce Momjian <bruce@momjian.us>
> wrote:
> >On Mon, Sep 3, 2018 at 01:30:33PM -0400, Tom Lane wrote:
> >> Bruce Momjian <bruce@momjian.us> writes:
> >> > What if we globally or locally cache the _cost_ of plans, so we
> >> > can consult that cache before planning and enable certain
> >optimizations?
> >>
> >> But what would you use as cache key? And how's this help if we
> >haven't
> >
> >Uh, I assume we would do what pg_stat_statements does and remove the
> >constants an hash that.
>
> That's not particularly cheap... Constants heavily influence planning
> choices, so I don't think they actually could be removed.
Oh.
> >> seen a similar query before in the session?
> >
> >Well, if it was global we could use output from another session.
> >
> >I guess my point is that this only used to turn on
> >micro-optimizations and maybe parallelism
>
> What kind of micro opts are you thinking of? The cases I remember
> are more in the vein of doing additional complex optimizations (join
> removal, transforming ORs into UNION, more complex analysis of
> predicates...).
>
> Parallelism would definitely benefit from earlier knowledge, although
> I suspect some base rel analysis might be more realistic, because it's
> far from guaranteed that queries are ever repeated in a similar enough
> manner.
Yes, no question that we would need something that could detect a
sufficient percentage of previous queries.
> > and JIT, so it doesn't have to be 100% accurate.
>
> JIT decision is done after main planning, so we know the cost.
Well, as I remember, we are considering disabling JIT in PG 11 because
of the use of fixed costs to trigger it. Could executor information
help decide to use JIT?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +