Mattias Kregert wrote:
>
> Darren King wrote:
> >
> > Would be nice if stuff like that (and the money and geometrics) could be
> > compiled in in the same manner that Apache is a basic web server that lets
> > you pick and choose modules/features you want to build into it.
> >
> > I don't know how big of a performance boost it provides in the cache, but
> > removing the functions associated with the char types shrank the pg_proc
> > table from 906 to 842 entries or a bit over 7%.
> >
> > Want to shrink it further? Of those remaining 842, _230_ are for the geometric
> > types! Throw in 25 more for the cash/money functions. Bloat city if you
> > never use these things. Thirty percent could be moved out to contrib and
> > not missed by most postgres users.
> >
> > I think a reasonable goal is to provide an sql server that meets the current sql
> > standard with the possibility of having other types and functionality available
> > as modules. These modules could be made into the template1 at compile time
> > or made and installed on a per-database basis. Make your server and database
> > with whatever you want in it.
>
> The problem with the contrib stuff is that most users find it too
> difficult to dig around in that dir and make and install stuff. The
> "contrib" name also give me the feeling that this is unsupported
> stuff/beta/not-to-be-used-in-production/to-be-removed etc.
>
> The nicest thing would be if contrib was changed to "modules", and
> everything was compiled and installed in /usr/local/pgsql/modules/.
> Then the user could install them by typing "INSMOD ORACLE" and then
> /usr/local/pgsql/modules/oracle/insmod.sql would be executed and
> install shared libraries and sql commands. "RMMOD ORACLE" would
> do the opposite. Just like Linux modules.
The difference here is that the entire Linux kernel (modules,
"standard" code, etc)must be memory resident at all times. This is
not the case with the majority of unix systems out there. Most
systems have copy on write pages, filesystem caching and memory
paging. The combined effect of these is that unused features do not
stay resident in memory, they are sent to the swap, or even discarded
and read in from the executable.
So this said, I believe there are things that can be done to help this
process along. If every feature is compiled to its respective object
files and then these files are linked together into one executable, a
page containing a desired feature might also contain unneeded code.
If instead, the different features are compiled to libraries and then
these libraries are linked to the "main" application to create the
executable, then each feature will start on a fresh page, which can
help keep the minimum number of pages resident, even though keeping
the whole program resident now takes more pages.
Ocie Mitchell