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

From Andres Freund
Subject Re: Caching query plan costs
Date
Msg-id 0039161C-4410-449B-A9F6-2756A22EEF35@anarazel.de
Whole thread Raw
In response to Re: Caching query plan costs  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Caching query plan costs  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers

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.
>> >
>> > 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?

I think there are much more pressing / more general things to do. Caching of JITed "hunks" and scaling the cost with
thenumber of JITed functions rather than one global cost.  Having to run queries multiple times for good plans just
isn'tthat interesting IMO. Especially for analytics queries, where JIT is interesting. 

Andres

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.


pgsql-hackers by date:

Previous
From: Andre_Mikulec
Date:
Subject: Re: Issues while building PG in MS Windows, using MSYS2 andMinGW-w64
Next
From: Michael Paquier
Date:
Subject: Re: Add SKIP LOCKED to VACUUM and ANALYZE