3 ms·
I'm not sure that I understand the big picture here. Is my summary correct? This optimization does not apply to Postgres in general, but only to citrus_fdw an
by adamtj 12y ago
I'm not sure that I understand the big picture here. Is my summary correct?
This optimization does not apply to Postgres in general, but only to citrus_fdw and other column-store foreign data wrappers.
The Postgres execution engine was designed to operate on a row-store. Even so, it can operate on a column-store via a foreign data wrapper like citrus_fdw. However, to do so it must currently reconstruct rows-at-a-time to fit its row-oriented nature. As a result, it cannot currently realize the potential performance benefits of using a column-store for certain queries.
This article is about an extension that adds some new column-at-a-time aggregate functions, then hooks into the Postgres executor to modify eligible query plans to use them. It thus enables Postgres to take advantage of the column-oriented nature of the citrus_fdw.
Is that an accurate way to look at it?
- alecco 12y agoYes. Also, buried inside is the reference of the original work by VectorWise this work was based on. "Vectorization vs. Compilation in Query Execution". They don't even mention the name. Not nice IMHO.
- ozgune 12y agoYes, it is. Can started by trying these ideas on Postgres' row store, and he thought that we could get good benefits particularly when columns in the database table had fixed-widths. Then again, making changes for both fast column projections and aggregations in Postgres didn't look too easy. Since we told him to go crazy in a short amount of time, the best way to do that seemed through the columnar store.