Re: Caching query plan costs - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Caching query plan costs
Date
Msg-id 20180903220129.GG25700@momjian.us
Whole thread Raw
In response to Re: Caching query plan costs  (Andres Freund <andres@anarazel.de>)
Responses Re: Caching query plan costs  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.
> > 
> > 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?
> 
> 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?

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


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Caching query plan costs
Next
From: Andre_Mikulec
Date:
Subject: Re: Issues while building PG in MS Windows, using MSYS2 andMinGW-w64