Re: Caching query plan costs

On September 3, 2018 3:01:29 PM PDT, Bruce Momjian <bruce(at)momjian(dot)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 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.

Andres

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