Re: alternative back-end block formats

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Christian Convey <christian(dot)convey(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: alternative back-end block formats
Date: 2014-01-28 16:00:23
Message-ID: 22979.1390924823@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-01-28 16:00:54 Re: jsonb and nested hstore
Previous Message Christian Kruse 2014-01-28 15:57:22 Re: Suspicion of a compiler bug in clang: using ternary operator in ereport()