Re: [HACKERS] Pluggable storage

Hi, Haribabu!

On Mon, Feb 5, 2018 at 2:22 PM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:

>
> On Tue, Jan 9, 2018 at 11:42 PM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
>
>>
>> Updated patches are attached.
>>
>
> To integrate the columnar store with the pluggable storage API, I found
> that
> there 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 table
> access method that the user wants for the table. HEAP is the default access
> method. 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 like
> CREATE 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 be
> created 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
> visible
> directly from pg_class and these will be stored in the storage specific
> catalog tables. A dependency is created for the original table as these
> storage
> specific tables must be created/dropped/altered whenever there is a change
> with 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*

1. https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2018_
Developer_Meeting#Minutes
2. http://rhaas.blogspot.com.by/2018/01/do-or-undo-there-is-no-vacuum.html

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company