Ashwin (copied) and I got a chance to go through the latest code from Andres' github repository. We would like to share some comments/quesitons:
The TupleTableSlot argument is well suited for row-oriented storage. For a column-oriented storage engine, a projection list indicating the columns to be scanned may be necessary. Is it possible to share this information with current interface? We realized that DDLs such as heap_create_with_catalog() are not generalized. Haribabu's latest patch that adds SetNewFileNode_function() and CreateInitFort_function() is a step towards this end. However, the current API assumes that the storage engine uses relation forks. Isn't that too restrictive? TupleDelete_function() accepts changingPart as a parameter to indicate if this deletion is part of a movement from one partition to another. Partitioning is a higher level abstraction as compared to storage. Ideally, storage layer should have no knowledge of partitioning. The tuple delete API should not accept any parameter related to partitioning. The API needs to be more accommodating towards block sizes used in storage engines. Currently, the same block size as heap seems to be assumed, as evident from the type of some members of generic scan object: typedef struct TableScanDescData { /* state set up at initscan time */ BlockNumber rs_nblocks; /* total number of blocks in rel */ BlockNumber rs_startblock; /* block # to start at */ BlockNumber rs_numblocks; /* max number of blocks to scan */ /* rs_numblocks is usually InvalidBlockNumber, meaning "scan whole rel" */ bool rs_syncscan; /* report location to syncscan logic? */ } TableScanDescData; Using bytes to represent this information would be more generic. E.g. rs_startlocation as bytes/offset instead of rs_startblock and so on. Asim