On Mon, Sep 3, 2018 at 04:13:40PM -0700, Andres Freund wrote: > On September 3, 2018 3:01:29 PM PDT, Bruce Momjian <br...@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 <br...@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 +
