Re: Improving executor performance

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Improving executor performance
Дата
Msg-id 20160714181710.sh4nt3ylzp3f55wy@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Improving executor performance  (Andreas Seltenreich <seltenreich@gmx.de>)
Ответы Re: Improving executor performance  (Andreas Seltenreich <seltenreich@gmx.de>)
Список pgsql-hackers
On 2016-07-14 20:04:03 +0200, Andreas Seltenreich wrote:
> Andres Freund writes:
> 
> > Having expression evaluation and slot deforming as a series of simple
> > sequential steps, instead of complex recursive calls, would also make it
> > fairly straightforward to optionally just-in-time compile those.
> 
> I don't think that JIT becomes easier by this change.  Constructing the
> IR for LLVM, libFirm or any other JIT library from expression trees is
> straightforward already.  It's probably more of a nuisance for those
> that already have some code/design on JIT-compiling expressions
> (vitessedb, ISP RAS, yours truly)

The problem is that the previous form has a lot of ad-hoc analysis
strewn in. The interesting part is getting rid of all that. That's what
the new ExecInitExpr2() does. The target form can be both evaluated more
efficiently in the dispatch manner in the patch, and quite simply
converted to a JIT - without duplicating the analysis code.  I did write
a small ad-hoc x86 jit, and it was really quite straightforward this
way.

What did you do with JIT and expression evaluation? You basically just
replaced the toplevel ExprState note with a different evalfunc, pointing
into your code?

Andres



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

Предыдущее
От: Andreas Seltenreich
Дата:
Сообщение: Re: Improving executor performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Issue in pg_catalog.pg_indexes view definition