Re: Pluggable Storage - Andres's take

On Tue, Nov 27, 2018 at 4:59 PM Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
wrote:

> Hi,
>
> On 2018/11/02 9:17, Haribabu Kommi wrote:
> > Here I attached the cumulative fixes of the patches, new API additions
> for
> > zheap and
> > basic outline of the documentation.
>
> I've read the documentation patch while also looking at the code and here
> are some comments.
>

Thanks for the review and apologies for the delay.
I have taken care of your most of the comments in the latest version of the
doc patches.

>
> + <para>
> +<programlisting>
> +TupleTableSlotOps *
> +slot_callbacks (Relation relation);
> +</programlisting>
> + API to access the slot specific methods;
> + Following methods are available;
> + <structname>TTSOpsVirtual</structname>,
> + <structname>TTSOpsHeapTuple</structname>,
> + <structname>TTSOpsMinimalTuple</structname>,
> + <structname>TTSOpsBufferTuple</structname>,
> + </para>
>
> Unless I'm misunderstanding what the TupleTableSlotOps abstraction is or
> its relations to the TableAmRoutine abstraction, I think the text
> description could better be written as:
>
> "API to get the slot operations struct for a given table access method"
>
> It's not clear to me why various TTSOps* structs are listed here? Is the
> point that different AMs may choose one of the listed alternatives? For
> example, I see that heap AM implementation returns TTOpsBufferTuple, so it
> manipulates slots containing buffered tuples, right? Other AMs are free
> to return any one of these? For example, some AMs may never use buffer
> manager and hence not use TTOpsBufferTuple. Is that understanding correct?
>

Yes, AM can decide what type of Slot method it wants to use.

Regards,
Haribabu Kommi
Fujitsu Australia