Re: Yet another vectorized engine - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Yet another vectorized engine
Date
Msg-id d0bc3bd6-9d99-7318-25de-6767842d6d22@postgrespro.ru
Whole thread Raw
In response to Re: Yet another vectorized engine  (Hubert Zhang <hzhang@pivotal.io>)
List 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 by date:

Previous
From: Sandro Santilli
Date:
Subject: Re: [postgis-devel] About EXTENSION from UNPACKAGED on PostgreSQL 13
Next
From: Peter Eisentraut
Date:
Subject: Re: vacuum verbose detail logs are unclear; log at *start* of eachstage