> On Tue, Apr 9, 2019 at 4:12 AM Haribabu Kommi <kommi.harib...@gmail.com> > wrote: > > On Sat, Apr 6, 2019 at 7:25 AM Andres Freund <and...@anarazel.de> wrote: >> >> 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?
I'm also curious about that. As far as I can see the main objection against that was that in this case the recovery process will depend on an extension, which could violate reliability. But I wonder if this argument is still valid for AM's, since the whole data is kind of depends on it, not only the recovery. Btw, can someone elaborate, why exactly generic_xlog is not efficient enough? I've went through the corresponding thread, looks like generic WAL records are bigger than normal one - is it the only reason?
