Christian Convey <christian.con...@gmail.com> writes: > On Tue, Jan 28, 2014 at 5:42 AM, Cédric Villemain > <ced...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
