Hannu Krosing <hannu@tm.ee> writes:
> On Wed, 2002-08-14 at 00:38, Tom Lane wrote:
>> For an embedded system I'd think you'd want to strip out the support
>> code for the unwanted types (ie, the utils/adt/ file(s)), not only the
>> catalog entries.
> But if the types themselves were installable, then it would also mean
> that unneeded utils/adt/ code would not be installed without need.
Only if someone went to the trouble of repackaging each such datatype
as a separate shared library. That's a lot more work than what I
understood Peter to be suggesting (namely, install the catalog entries
a little later during initdb).
>> I'd also be concerned about the performance hit (loadable
>> functions are noticeably slower than built-ins).
> Really ?
Yup.
> How much is the performance hit ?
I'm not sure, but it's nontrivial. I recall Oleg and Teodor moaning
about the poor performance of GiST-index contrib modules awhile back,
at a time when we did fmgr_info for index access functions once per
call instead of caching the results in the index' relcache entry.
It didn't hurt for built-in access functions but you sure noticed it
for loadable ones.
It might be feasible to persuade fmgr.c or dfmgr.c to short-circuit
lookups of dynamic functions after the first time, by keeping an
internal lookup table comparable to the compile-time-constant table
we have for builtins. This would not make the problem go away, but
it would lessen the performance hit...
regards, tom lane
