On Tue, Nov 27, 2018 at 4:59 PM Amit Langote <langote_amit...@lab.ntt.co.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
