Re: Caching query plan costs

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Caching query plan costs
Дата
Msg-id 0039161C-4410-449B-A9F6-2756A22EEF35@anarazel.de
обсуждение исходный текст
Ответ на Re: Caching query plan costs  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Caching query plan costs  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Andre_Mikulec
Дата:
Сообщение: Re: Issues while building PG in MS Windows, using MSYS2 andMinGW-w64
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Add SKIP LOCKED to VACUUM and ANALYZE