Re: Pluggable storage

On Sat, Aug 13, 2016 at 2:15 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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