> 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?
Well, it is really only 50k per installation, not 50k per backend
because they all share the same executable in the buffer cache.
The problem with breaking it up, as I see it, is that all of a sudden
the regression tests and the nice descriptions of \do, \df, etc are much
harder to implement.
Maybe in six months, when we will have resolved all of the
performance/SQL92/feature issues, this will be a good use of our time,
but at this point, trying to keep all that straight while working on
much more important issues to end-users is hard to justify.
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
In response to
pgsql-hackers by date
|Next:||From: wward||Date: 1998-03-25 02:07:23|
|Subject: RE: [HACKERS] Data type removal|
|Previous:||From: Bruce Momjian||Date: 1998-03-25 01:53:28|
|Subject: Re: [DOCS] Re: [HACKERS] PostgreSQL Reference Guide|