Re: [HACKERS] Data type removal

The Hermit Hacker said:
>
> On Tue, 24 Mar 1998, Brandon Ibach wrote:
> > 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,
>
> I don't know about Apache, but is there any noticeable performance
> difference between having extra modules installed or not installed? It
> makes the binary slightly larger, but does it change performance?
>
I can't say for sure what effect this would have on performance.
However, what example can you give of a monolithic piece of software
that is superior to a slim, well-designed core with an architecture
for expansion? In fact, if you want to talk about what puts the
Postgres in PostgreSQL, I think the ability to dynamically add types
and functions is a big part of that. I would say that a large part of
the reason that packages like MySQL exist is so that people have an
option of a light-weight, simple SQL database. Why can't we serve
that same purpose? Never consider unneeded resource consumption
lightly, as it can be a very important factor in someone's choice of a
database package.

> > 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.
>
> If yours is an improvement over what we have in contrib, why not
> submit it?
>
Perhaps I will, but my point is that I had a *choice* to do my own
implementation, rather than being forced to use one that didn't suit
my needs as well.

> > 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?
>
> Not if it removes the Postgres from PostgreSQL...I don't have the
> ip_and_mac contrib stuff loaded, because I never think of it. I know I
> can use it, mind you, just never think of adding it in...
>
Since when do geometric types put the Postgres in PostgreSQL? Or
IP and MAC types, for that matter? I can use the improvements in 6.3,
but I haven't upgraded yet because it will be a bit of a job. Is
there something we can throw in to solve that, or is it maybe
something I have to do if I want the benefits?

> > 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.
>
> As I stated earlier, if someone wants to add a
> '--without-geometry' option to configure that removes it, I have no
> problem with that...but it will only be to remove the feature, not add it
> in. Hell, I'm probably one that would even make use of it, since, right
> now, I don't use the geometric types either...but the default is to have
> everything included. I don't want to have to think about it someday when
> I decide I want to use those geometric types...
>
You may notice that the option I suggested was one that could be
invoked to remove the feature. In other words, the default is to have
the feature included unless the user asks for it to not be. All I'm
saying is, don't force the users to run a Postgres which has unneeded
baggage.

-Brandon :)