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 :-(
regards, tom lane