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.
