Data type removal
От | Brandon Ibach |
---|---|
Тема | Data type removal |
Дата | |
Msg-id | 199803241221.GAA09991@vweb.infomansol.com обсуждение исходный текст |
Ответы |
Re: [HACKERS] Data type removal
Re: [HACKERS] Data type removal Re: [HACKERS] Data type removal |
Список | pgsql-hackers |
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 used is much like compiling extra modules into my Apache web server because they're "kinda neat", even though they won't be used. Also, if we follow the idea that we should have as many unique features in the backend as possible, we could end up with all sorts of features that are only used by a subset of users. For instance, I don't use the geometric types, but I do use a soundex type which I created. Why isn't the soundex type a standard part of the backend? I, personally, am glad it's not, because I like the version of this type that I created a lot better than the one that's in contrib. 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? 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. -Brandon :)
В списке pgsql-hackers по дате отправления: