Re: Yet another vectorized engine
От | Konstantin Knizhnik |
---|---|
Тема | Re: Yet another vectorized engine |
Дата | |
Msg-id | 893a9310-94d0-44de-76ec-8fdb3a6e3b4b@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Yet another vectorized engine (Hubert Zhang <hzhang@pivotal.io>) |
Ответы |
Re: Yet another vectorized engine
Re: Yet another vectorized engine |
Список | pgsql-hackers |
On 12.02.2020 13:12, Hubert Zhang wrote:
On Tue, Feb 11, 2020 at 1:20 AM Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote:
So looks like PG-13 provides significant advantages in OLAP queries comparing with 9.6!
Definitely it doesn't mean that vectorized executor is not needed for new version of Postgres.
Once been ported, I expect that it should provide comparable improvement of performance.
But in any case I think that vectorized executor makes sense only been combine with columnar store.Thanks for the test. +1 on vectorize should be combine with columnar store. I think when we support this extensionon master, we could try the new zedstore.I'm not active on this work now, but will continue when I have time. Feel free to join bring vops's feature into this extension.ThanksHubert Zhang
I have ported vectorize_engine to the master.
It takes longer than I expected: a lot of things were changed in executor.
Results are the following:
par.warkers | PG9_6 vectorize=off | PG9_6 vectorize=on | master vectorize=off jit=on | master vectorize=off jit=off | master vectorize=on jit=ofn | master vectorize=on jit=off |
0 | 36 | 20 | 16 | 25.5 | 15 | 17.5 |
4 | 10 | - | 5 | 7 | - | - |
So it proves the theory that JIT provides almost the same speedup as vector executor (both eliminates interpretation overhead but in different way).
I still not sure that we need vectorized executor: because with standard heap it provides almost no improvements comparing with current JIT version.
But in any case I am going to test it with vertical storage (zedstore or cstore).
-- Konstantin Knizhnik Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: