On Wed, 2009-01-21 at 17:46 -0600, Kevin Grittner wrote:
> >>> Bruce Momjian <bruce@momjian.us> wrote:
> > It is cost vs. benefit. No one is saying plugabiity is bad, only
> that
> > in this case it is more costly than beneficial
>
> Just curious -- are we talking execution time costs or programming
> costs because of increased code complexity?
The execution time of a pluggable index would be identical to a
non-pluggable index. There is zero overhead in having the capability,
since we already use a function pointer mechanism in the existing code.
There is not really any overhead in having 10 or 50 plugins; the
recovery processing time is determined by the efficiency of the plugin
and how many WAL message need to be processed. For example, if you have
more TypeX indexes then recovery will spend more time recovering TypeX
indexes. If you have no TypeX indexes, that module would only be asked
to startup() and cleanup(), but nothing else.
The code complexity is exactly the same whether you write it as a plugin
or a patch against core. The API is identical. The key difference is
that users get to choose whether they use a plugin, or not, whereas
without the plugin you are limited to index types that have been
included with core Postgres.
Just as with some PL languages, some pluggable indexes may gain a
reputation as buggy and fall into disuse. Others may become popular and
be invited to join core, where they will gain further trust.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
