Re: bad JIT decision

Поиск
Список
Период
Сортировка
От Scott Ribe
Тема Re: bad JIT decision
Дата
Msg-id 9408F5F7-AD97-4E31-94BD-DAB5112E30F3@elevated-dev.com
обсуждение исходный текст
Ответ на Re: bad JIT decision  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
> On Jul 24, 2020, at 4:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Yeah.  I'm fairly convinced that the v12 defaults are far too low,
> because we are constantly seeing complaints of this sort.


They are certainly too low for our case; not sure if for folks who are not partitioning if they're way too low.

The passive-aggressive approach would really not be good general advice for you, but I'm actually glad that in our case
theywere low enough to get our attention early ;-) 

I think I will disable optimization, because with our partitioning scheme we will commonly see blow ups of optimization
timelike this one. 

The inlining time in this case is still much more than the query, but it is low enough to not be noticed by users, and
Ithink that with different variations of the parameters coming in to the query, that for the slower versions (more
partitionsrequiring actual scans), inlining will help. Slowing down the fastest while speeding up the slower is a trade
offwe can take. 


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

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