On Mon, 26 Jul 2004, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Postgres was, however, one of the systems that in fact pioneered
> > pluggable storage managers. So we could say we're already one
> > generation ahead of everyone else: we had switchable storage managers,
> > realized we didn't need them, and got rid of them.
>
> We do actually still have the smgr switch interface, so in theory you
> could plug in a new storage manager just as well as you could back in
> the Berkeley days. If anything better --- smgr is now allowed to handle
> stuff that was kluged in upper layers back then.
>
> I think the reason that this feature is moribund is largely that
> substituting behaviors at that low level stopped being interesting some
> time ago. In modern systems the equivalent behavior is down inside the
> kernel device driver, if not in the storage device itself (think SAN,
> RAID controllers, etc) and it's just not useful to try to manage it
> inside an unprivileged-application database.
>
> The complaint that's commonly leveled against the MySQL table-handler
> design is that it puts the switch at too *high* a level --- there are
> very significant semantic issues that are left to the table handler
> (eg locking), which means that an application is pretty much locked into
> the handler it was designed for. MySQL isn't so much one database as
> it is three or four databases with roughly similar APIs. I don't think
> it's either practical or interesting to try to introduce an equivalent
> layering into Postgres.
>
> There might be some way to design an intermediate switching layer where
> interesting behavioral changes could be introduced without breaking
> application API expectations. But we don't have one, and I think it'd
> be quite a bit of work to introduce one, even if you could get people
> to buy into the idea in advance of proof of usefulness :-(
I've looked into this.
The problem is that many storage management systems also want to take
higher level control of indexing. They also often do their own WAL and
PITR. Some do their own buffer management, locking and replication/load
management too. So, as you say, its hard say where an interface should be
abstracted.
Its definately a difficult issue.
Gavin
