Re: Caching query plan costs

On Mon, Sep 3, 2018 at 04:13:40PM -0700, Andres Freund wrote:
> On September 3, 2018 3:01:29 PM PDT, Bruce Momjian <bruce@momjian.us>
> wrote:
> >On Mon, Sep 3, 2018 at 02:53:59PM -0700, Andres Freund wrote:
> >> On 2018-09-03 14:56:28 -0400, Bruce Momjian wrote:
> >> > On Mon, Sep 3, 2018 at 11:42:31AM -0700, Andres Freund wrote:
> >> > > >  and JIT, so it doesn't have to be 100% accurate.
> >> > >
> >> > > JIT decision is done after main planning, so we know the cost.
> >> I don't think so. The issues with JIT planning are more that it's
> >> costing is simplistic (for good-ish reason, to avoid increasing
> >> the number of plans), and that there's no caching (lots of
> >> infrastructure work needed).
> >
> >Uh, yeah, that was my question.  If we knew the cost was high before
> >we plan, could we realistically increase the number of plans to avoid
> >the cost-trigger issue?
>
> I think there are much more pressing / more general things to
> do. Caching of JITed "hunks" and scaling the cost with the number
> of JITed functions rather than one global cost.  Having to run
> queries multiple times for good plans just isn't that interesting
> IMO. Especially for analytics queries, where JIT is interesting.

I agree it isn't useful for JIT alone but if it can be used for multiple
purposes, it might be worth it.

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