On Sat, Apr 6, 2019 at 7:25 AM Andres Freund <andres@anarazel.de> wrote:
Hi,
In this email I want to give a brief status update of the table access method work - I assume that most of you sensibly haven't followed it into all nooks and crannies.
I want to thank Haribabu, Alvaro, Alexander, David, Dmitry and all the others that collaborated on making tableam happen. It was/is a huge project.
A big thank you Andres for your enormous efforts in this patch.
Without your involvement, this patch couldn't have been made into v12.
With regards to storing the rows themselves, the second biggest limitation is a limitation that is not actually a part of tableam itself: WAL. Many tableam's would want to use WAL, but we only have extensible WAL as part of generic_xlog.h. While that's useful to allow prototyping etc, it's imo not efficient enough to build a competitive storage engine for OLTP (OLAP probably much less of a problem). I don't know what the best approach here is - allowing "well known" extensions to register rmgr entries would be the easiest solution, but it's certainly a bit crummy.
I got the same doubt when i looked into some of the UNDO patches
where it tries to modify the core code to add UNDO specific WAL types.
Different AM's may need different set of operations to be WAL logged,
so it may be better for the AM's to register their own types?