Re: alternative back-end block formats

Christian Convey <christian(dot)convey(at)gmail(dot)com> writes:
> On Tue, Jan 28, 2014 at 5:42 AM, Cdric Villemain <cedric(at)2ndquadrant(dot)com>wrote:
>> As written in the meeting notes, Tom Lane revealed an interest in
>> pluggable storage. So it might be interesting to check that.
>> https://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting

> Thanks. I just read those meeting notes, and also Josh Berkus' blog on the
> topic:
> http://www.databasesoup.com/2013/05/postgresql-new-development-priorities-2.html

> I was only thinking to enable pluggable operations on a single, specified
> heap page, probably as a function of which table owned the page. Josh's
> blog seems to describe something a little broader in scope, although I
> can't tell from that post exactly what functionality that entails.

> Either way, this sounds like something I'd enjoy pitching in on, to
> whatever extent I could be useful. Has anyone started work on this yet?

Nope, but it's still on the radar screen.

There are a couple of really huge issues that would have to be argued out
before any progress could be made.

One is that tuple layout (particularly tuple header format) is something
known in detail throughout large parts of the system. This is a PITA if
the storage layer would like to use some other tuple format, but is it
worthwhile or even possible to abstract it?

Another is that we've got whole *classes* of utility commands that are
specifically targeted to the storage engine we've got. VACUUM, CLUSTER,
ALTER TABLE SET TABLESPACE for example. Not to mention autovacuum.
It's not clear where these would fit if we tried to define a storage
engine API layer.

regards, tom lane