Re: bad JIT decision

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: bad JIT decision
Дата
Msg-id 20200727230256.GA31992@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: bad JIT decision  (Scott Ribe <scott_ribe@elevated-dev.com>)
Ответы Re: bad JIT decision  (Andres Freund <andres@anarazel.de>)
Список pgsql-general
On 2020-Jul-27, Scott Ribe wrote:

> > On Jul 27, 2020, at 4:00 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > 
> > I don't quite understand why is it that a table with 1000 partitions
> > means that JIT compiles the thing 1000 times.  Sure, it is possible that
> > some partitions have a different column layout, but it seems an easy bet
> > that most cases are going to have identical column layout, and so tuple
> > deforming can be shared.  (I'm less sure about sharing a compile of an
> > expression, since the varno would vary. But presumably there's a way to
> > take the varno as an input value for the compiled expr too?)  Now I
> > don't actually know how this works so please correct if I misunderstand
> > it.
> 
> I'm guessing it's because of inlining. You could optimize a function
> that takes parameters, no problem. But what's happening is inlining,
> with parameters, then optimizing.

Are you saying that if you crank jit_inline_above_cost beyond this
query's total cost, the problem goes away?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-general по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: bad JIT decision
Следующее
От: David Rowley
Дата:
Сообщение: Re: bad JIT decision