From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP]Vertical Clustered Index (columnar store extension) |
Date: | 2017-01-18 03:25:28 |
Message-ID: | 06154ef0-3bd6-a183-4906-3697be106742@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/29/16 10:55 PM, Haribabu Kommi wrote:
> Fujitsu was interested in developing a columnar storage extension with
> minimal
> changes the server backend.
>
> The columnar store is implemented as an extension using index access
> methods.
> This can be easily enhanced with pluggable storage methods once they are
> available.
>
> A new index method (VCI) is added to create columnar index on the table.
I'm confused. You say that you are adding an index access method, for
which we have a defined extension mechanism, but the code doesn't do
that. Instead, it sprinkles a bunch of hooks through the table access
code. So you are really adding ways to add alternatives to heap
storage, except we have no way to know whether these hooks have been
designed with any kind of generality in mind. So is it an index access
method or a table access method?
Either way, you shouldn't need a new relkind. Note that all indexes
have the same relkind, even if they use different access methods.
I think there are two ways to integrate column storage into PostgreSQL:
One is to use the FDW interface. That has been done before, see
cstore_fdw. The other is to define a storage manager extension
interface. That has been tried but has not been completed yet. Adding
a bunch of custom hooks all over the place seems worse than both of those.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-01-18 03:34:51 | Re: Bug in Physical Replication Slots (at least 9.5)? |
Previous Message | Peter Eisentraut | 2017-01-18 02:57:57 | Re: [PROPOSAL] Temporal query processing with range types |