Re: [HACKERS] Pluggable storage
| От | Alexander Korotkov |
|---|---|
| Тема | Re: [HACKERS] Pluggable storage |
| Дата | |
| Msg-id | CAPpHfdvZpxxwcP1LMXveUT5F0-8aCG+jSKQ-qBH5V_ykipuMEQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Pluggable storage (Haribabu Kommi <kommi.haribabu@gmail.com>) |
| Ответы |
Re: [HACKERS] Pluggable storage
Re: [HACKERS] Pluggable storage |
| Список | pgsql-hackers |
Hi, Haribabu!
On Mon, Feb 5, 2018 at 2:22 PM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
On Tue, Jan 9, 2018 at 11:42 PM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote:Updated patches are attached.
To integrate the columnar store with the pluggable storage API, I found thatthere are couple of other things also that needs to be supported.1. Choosing the right table access method for a particular table?I am thinking of adding a new table option to let the user select the correct tableaccess method that the user wants for the table. HEAP is the default accessmethod. This approach may be simple and doesn't need any syntax changes.Or Is it fine to add syntax "USING method" to CREATE TABLE similar likeCREATE INDEX?comments?
Sure, user needs to specify particular table access method when creating a table. "USING method" is good for me. I think it's better to reuse already existing syntax rather than reinventing something new.
2. As the columnar storage needs many other relations that are needs to becreated along with main relation.
That's an interesting point. During experimenting on some new index access methods I also have to define some kind of "internal" relations invisible for user, but essential for main relation functionality. I've made them in hackery manner, and I think legal mechanism for them would be very good.
As these extra relations are internal to the storage and shouldn't be visibledirectly from pg_class and these will be stored in the storage specificcatalog tables. A dependency is created for the original table as these storagespecific tables must be created/dropped/altered whenever there is a changewith the original table.
I think that internal relations should be visible from pg_class, otherwise it wouldn't be possible to define dependencies over them. But they should have different relkind, so they wouldn't be messed up with regular relations.
Is it fine to add new API while creating/altering/drop the table to get the control?or to use only exiting processutility hook?
I believe that we need some generic way for defining internal relations, not hooks. For me it seems like useful feature for further development of both index access methods and table access methods.
During developer meeting [1], I've proposed to reorder patches so that refactoring patches go first and API introduction patches go afterwards. That would make possible to commit some of refactoring patches earlier without necessary committing API in the same release cycle. If no objection, I would do that reordering.
BTW, EnterpriseDB announces zheap table access method (heap with undo log) [2]. I think this is great, and I'm looking forward for publishing zheap in mailing lists. But I'm concerning about its compatibility with pluggable table access methods API. Does zheap use table AM API from this thread? Or does it just override current heap and needs to be adopted to use table AM API? Or does it implements own API?
Links
------
Alexander Korotkov
Postgres Professional: http://www.postg
The Russian Postgres Company
Alexander Korotkov
Postgres Professional: http://www.postg
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: