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

From Konstantin Knizhnik
Subject Re: Yet another vectorized engine
Date
Msg-id d20a9486-dd45-acdd-8be1-95f6d62ff0ff@postgrespro.ru
Whole thread Raw
In response to Re: Yet another vectorized engine  (Hubert Zhang <hzhang@pivotal.io>)
Responses Re: Yet another vectorized engine  (Hubert Zhang <hzhang@pivotal.io>)
List pgsql-hackers


On 02.12.2019 4:15, Hubert Zhang wrote:

The prototype extension is at https://github.com/zhangh43/vectorize_engine

I am very sorry, that I have no followed this link.
Few questions concerning your design decisions:

1. Will it be more efficient to use native arrays in vtype instead of array of Datum? I think it will allow compiler to generate more efficient code for operations with float4 and int32 types.
It is possible to use union to keep fixed size of vtype.
2. Why VectorTupleSlot contains array (batch) of heap tuples rather than vectors (array of vtype)?
3. Why you have to implement your own plan_tree_mutator and not using expression_tree_mutator?
4. As far as I understand you now always try to replace SeqScan with your custom vectorized scan. But it makes sense only if there are quals for this scan or aggregation is performed.
In other cases batch+unbatch just adds extra overhead, doesn't it?
5. Throwing and catching exception for queries which can not be vectorized seems to be not the safest and most efficient way of handling such cases.
May be it is better to return error code in plan_tree_mutator and propagate this error upstairs?
6. Have you experimented with different batch size? I have done similar experiments in VOPS and find out that tile size larger than 128 are not providing noticable increase of performance.
You are currently using batch size 1024 which is significantly larger than typical amount of tuples on one page.
7. How vectorized scan can be combined with parallel execution (it is already supported in9.6, isn't it?)

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

pgsql-hackers by date:

Previous
From: Gareth Palmer
Date:
Subject: Re: [PATCH] Implement INSERT SET syntax
Next
From: Michael Paquier
Date:
Subject: Re: fe-utils - share query cancellation code