Hi, On 2018-11-26 17:55:57 -0800, Andres Freund wrote: > FWIW, now that oids are removed, and the tuple table slot abstraction > got in, I'm working on rebasing the pluggable storage patchset ontop of > that.
I've pushed a version to that to the git tree, including a rebased version of zheap: https://github.com/anarazel/postgres-pluggable-storage https://github.com/anarazel/postgres-pluggable-zheap I'm still working on moving some of the out-of-access/zheap modifications into pluggable storage (see e.g. the first commit of the pluggable-zheap series). But this should allow others to start on a more recent codebasis. My next steps are: - make relation creation properly pluggable - remove the typedefs from tableam.h, instead move them into the TableAmRoutine struct. - Move rs_{nblocks, startblock, numblocks} out of TableScanDescData - Move HeapScanDesc and IndexFetchHeapData out of relscan.h - See if the slot in SysScanDescData can be avoided, it's not exactly free of overhead. - remove ExecSlotCompare(), it's entirely unrelated to these changes imo (and in the wrong place) - rename HeapUpdateFailureData et al to not reference Heap - split pluggable storage patchset, to commit earlier: - EvalPlanQual slotification - trigger slotification - split of IndexBuildHeapScan out of index.c I'm wondering whether we should add table_beginscan/table_getnextslot/index_getnext_slot using the old API in an earlier commit that then could be committed separately, allowing the tablecmd.c changes to be committed soon. I'm wondering whether we should change the table_beginscan* API so it provides a slot - pretty much every caller has to do so, and it seems just as easy to create/dispose via table_beginscan/endscan. Further tasks I'm not yet planning to tackle, that I'd welcome help on: - pg_dump support - pg_upgrade testing - I think we should consider removing HeapTuple->t_tableOid, it should imo live entirely in the slot Greetings, Andres Freund
