On Sat, Aug 13, 2016 at 2:15 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Many have expressed their interest in this topic, but I haven't seen any > design of how it should work. That's it. My design presented at PGCon was very sketchy, and I didn't deliver any prototype yet. > Here's my attempt; I've been playing with > this for some time now and I think what I propose here is a good initial > plan. Great! It's nice to see you're working in this direction! > This will allow us to write permanent table storage that works > differently than heapam.c. At this stage, I haven't throught through > whether this is going to allow extensions to define new storage modules; > I am focusing on AMs that can coexist with heapam in core. > So, as I get you're proposing extendability to replace heap with something another but compatible with heap (with executor nodes, index access methods and so on). That's good, but what alternative storage access methods could be? AFAICS, we can't fit here, for instance, another MVCC implementation (undo log) or in-memory storage or columnar storage. However, it seems that we would be able to make compressed heap or alternative HOT/WARM tuples mechanism. Correct me if I'm wrong. ISTM you're proposing something quite orthogonal to my view of pluggable storage engines. My idea, in general, was to extend FDW mechanism to let it be something manageable inside database (support for VACUUM, defining indexes and so on). But imperative was that it should have its own executor nodes, and it doesn't have to compatible with existing index access methods. Therefore, I think my design presented at PGCon and your current proposal are about orthogonal features which could coexist. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company