Brandon writes:
> I, for one, am in favor of converting some of the type packages to
> loadable modules. Having those in the backend when they aren't being
...
> As far as the whole performance-improvement issue, I can say that
> if the backend is, say, 50K smaller due to the removal of those
> functions, that's just that much less swapping and that much more
> memory that's available for the OS buffer cache. Isn't that an
> improvement worth considering?
No. If the functions are not used, the pages of the executable
that contain them are never loaded. So there is no effective memory impact
from having these where they are.
As far as disk space, disk costs $0.03 per megabyte these days so saving
50Kb is completely insignificant.
It may be a good idea to make the system more modular, but there are
thousands of good ideas for improving it. I think we would be better
served by spending our time on something that makes a difference, not
just mindlessly pushing code around for no particular benefit.
> How about this as a compromise. We make these packages available
> in the contrib or other such area as loadable modules as well as
> making them available right in the main backend code, but setup
> configure options to enable/disable them, so when I compile, I can say
> "--without-geometry" to compile without those types and functions. If
> I want to add them back in later, I can compile the loadable module
> version and add them in.
I don't particularly like this model of adding extensions either. It implies
that you have to rerun configure and build the whole system to add a module.
In fact, all that is needed is to build the module and run the setup
scripts and the running database picks up the new functionality.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- Linux. Not because it is free. Because it is better.