From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Caching query plan costs |
Date: | 2018-09-03 18:56:28 |
Message-ID: | 20180903185628.GF25700@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)momjian(dot)us>
> wrote:
> >On Mon, Sep 3, 2018 at 01:30:33PM -0400, Tom Lane wrote:
> >> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)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 +
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2018-09-03 20:05:23 | Re: A strange GiST error message or fillfactor of GiST build |
Previous Message | Alvaro Herrera | 2018-09-03 18:56:14 | Re: Out arguments name of "pg_identify_object_as_address" function in 9.5.14 and 11beta3 |