Re: Everything is now "required by the database system"
От | Tom Lane |
---|---|
Тема | Re: Everything is now "required by the database system" |
Дата | |
Msg-id | 862.1029270724@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Everything is now "required by the database system" (Hannu Krosing <hannu@tm.ee>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: