Re: Pluggable Indexes

Josh Berkus <josh(at)agliodbs(dot)com> writes:

> Right. And I'm saying that pluggability is PostgreSQL's main reason for
> existence, if you look at our place in the future of databases. So it's worth
> paying *some* cost, provided that the cost/benefit ratio works for the
> particular patch.

I agree that pluggability is a huge deal for Postgres. But note that the
interface is critical. If we provided a plugin architecture for functions and
operators which was simply a hook where you replaced part of the
infrastructure of the parser and executor it would be pointless.

Instead we provide an interface where your function has to know as little as
possible about the rest of the system. And the parser and executor get enough
information about your function that they can do most of the work. That you
can create a new operator in Postgres *without* knowing how operators actually
are implemented and without worrying about what other operators exist is what
makes the feature so useful.

This is made a lot harder with WAL because a) it spans the entire cluster, not
just a database so any meta-information has to be stored somewhere global and
b) the consequences for getting something wrong are so much more dire. The
entire cluster is dead and can't even be restored from backup.

> To rephrase: I can't judge the rmgr patch one way or the other. I'm only
> objecting to the idea expressed by Heikki and others that pluggable indexes are
> stupid and unnecessary.

Well we support pluggable indexes -- they just can't be recoverable right now.
Presumably if they're merged into the core database they would have
recoverability added like how GIST progressed.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning