Re: Yet another vectorized engine

Поиск
Список
Период
Сортировка
От Konstantin Knizhnik
Тема Re: Yet another vectorized engine
Дата
Msg-id d0bc3bd6-9d99-7318-25de-6767842d6d22@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Yet another vectorized engine  (Hubert Zhang <hzhang@pivotal.io>)
Список pgsql-hackers

On 27.02.2020 11:09, Hubert Zhang wrote:
> Hi Konstantin,
> I also vimdiff nodeAgg.c in your PG13 branch with nodeAgg.c in pg's 
> main repo.
> Many functions has changed from PG96 to PG13, e.g. 
> 'advance_aggregates', 'lookup_hash_entry'
> The vectorized nodeAgg seems still follow the PG96 way of implementing 
> these functions.
> In general, I think we'd better port executor of PG13 to vectorized 
> executor of PG13 instead of merge some PG13 code into vectorized 
> executor of PG96 to make it works. Because It's hard to determine 
> which functions need to be merged and it's buggy if the executor code 
> of both PG13 and PG96 exist in one branch.
>
> What's your opinion?
>

In new version of Postgres all logic of aggregates transition is 
encapsulated in expression and performed by execExprInterp or generated 
GIT code.
If we not going to embed vectorize engine in kernel and continue to 
develop it as extension, then I do not have any good idea how to achieve 
it without
copying and patching code of ExecInterpExpr.

In any case, the current prototype doesn't show any noticeable 
performance improvement  comparing with existed executor with enabled JIT.
And providing vectorized version of ExecInterpExpr will not help to 
increase speed (according to profile time is spent in other places).

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




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

Предыдущее
От: Sandro Santilli
Дата:
Сообщение: Re: [postgis-devel] About EXTENSION from UNPACKAGED on PostgreSQL 13
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: vacuum verbose detail logs are unclear; log at *start* of eachstage