Thread: Re: [HACKERS] char types gone.
> > If for posterity alone, I'm willing to move the char[24816] code to contrib. > > I already have the create and load statements in an sql file, just have to > > polish the Makefile a little. If not with the distribution, then perhaps > > this could be at the web site for downloading. > > > > Having the code available for loading might be easier for persons such as > > Tatsuo instead of having their users complain of something disappearing. > > > > My only intention in doing this is to lighten up the postgres core, not to > > force others to change their existing code. > > Unless there is a proven performance boost to removing things from > the core, which, at this point in time, hasn't been demonstrated, > *nothing* should be removed from the core... > > ...in fact, I want to bring in the IP code from contrib as part of > the core yet... Would be nice if stuff like that (and the money and geometrics) could be compiled in in the same manner that Apache is a basic web server that lets you pick and choose modules/features you want to build into it. I don't know how big of a performance boost it provides in the cache, but removing the functions associated with the char types shrank the pg_proc table from 906 to 842 entries or a bit over 7%. Want to shrink it further? Of those remaining 842, _230_ are for the geometric types! Throw in 25 more for the cash/money functions. Bloat city if you never use these things. Thirty percent could be moved out to contrib and not missed by most postgres users. I think a reasonable goal is to provide an sql server that meets the current sql standard with the possibility of having other types and functionality available as modules. These modules could be made into the template1 at compile time or made and installed on a per-database basis. Make your server and database with whatever you want in it. Why force others to have functionality 'x', 'y' and 'z' when they only want 'y'? darrenk
> Would be nice if stuff like that (and the money and geometrics) could be > compiled in in the same manner that Apache is a basic web server that lets > you pick and choose modules/features you want to build into it. > > I don't know how big of a performance boost it provides in the cache, but > removing the functions associated with the char types shrank the pg_proc > table from 906 to 842 entries or a bit over 7%. > > Want to shrink it further? Of those remaining 842, _230_ are for the geometric > types! Throw in 25 more for the cash/money functions. Bloat city if you > never use these things. Thirty percent could be moved out to contrib and > not missed by most postgres users. > Yes, but if they are never referenced, the cache is empty for those types. Unless there is some performance change with their removal, why remove them? Disk space of binary? -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.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)
On Mon, 23 Mar 1998, Bruce Momjian wrote:
> > Would be nice if stuff like that (and the money and geometrics) could be
> > compiled in in the same manner that Apache is a basic web server that lets
> > you pick and choose modules/features you want to build into it.
> >
> > I don't know how big of a performance boost it provides in the cache, but
> > removing the functions associated with the char types shrank the pg_proc
> > table from 906 to 842 entries or a bit over 7%.
> >
> > Want to shrink it further? Of those remaining 842, _230_ are for the geometric
> > types! Throw in 25 more for the cash/money functions. Bloat city if you
> > never use these things. Thirty percent could be moved out to contrib and
> > not missed by most postgres users.
> >
>
> Yes, but if they are never referenced, the cache is empty for those
> types. Unless there is some performance change with their removal, why
> remove them? Disk space of binary?
I have to agree here...unless a noticeable performance improvement
can be demonstrated, I really don't like a trend that moves towards
removing core features that make us unique, just cause it makes a table
just a little smaller...*shrug*
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Mon, 23 Mar 1998, The Hermit Hacker wrote: > On Mon, 23 Mar 1998, Bruce Momjian wrote: > > > > Would be nice if stuff like that (and the money and geometrics) could be > > > compiled in in the same manner that Apache is a basic web server that lets > > > you pick and choose modules/features you want to build into it. > > > > > > I don't know how big of a performance boost it provides in the cache, but > > > removing the functions associated with the char types shrank the pg_proc > > > table from 906 to 842 entries or a bit over 7%. > > > > > > Want to shrink it further? Of those remaining 842, _230_ are for the geometric > > > types! Throw in 25 more for the cash/money functions. Bloat city if you > > > never use these things. Thirty percent could be moved out to contrib and > > > not missed by most postgres users. > > > > > > > Yes, but if they are never referenced, the cache is empty for those > > types. Unless there is some performance change with their removal, why > > remove them? Disk space of binary? > > I have to agree here...unless a noticeable performance improvement > can be demonstrated, I really don't like a trend that moves towards > removing core features that make us unique, just cause it makes a table > just a little smaller...*shrug* I'm also thinking about JDBC. If you remove some features out of the core, and reorganise what OID's are associated with the types, then we would have a big performance hit when the driver starts up, and possibly make the driver even larger than it is now. -- Peter T Mount petermount@earthling.net or pmount@maidast.demon.co.uk Main Homepage: http://www.demon.co.uk/finder Work Homepage: http://www.maidstone.gov.uk Work EMail: peter@maidstone.gov.uk
On Tue, 24 Mar 1998, Peter T Mount wrote:
> I'm also thinking about JDBC. If you remove some features out of the core,
> and reorganise what OID's are associated with the types, then we would
> have a big performance hit when the driver starts up, and possibly make
> the driver even larger than it is now.
From discussions that the core have had on this topic over the
past couple of weeks, I think it will take *alot* to convince us to remove
core features.
char2/4/8/16 disappears *only* because they were redundant...it
had nothing to do with reducing the sizes of tables...char2 maps to
char(2), so why have both. Stuff like the geometric types aren't
redundant...they are themselves the "base" types...
Once v6.3.1 is finished up, I'm going to be looking at merging in
the ip_and_mac contrib stuff, and I think that Thomas is considering
moving the 64bit stuff into the core from contrib...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
I think Darren brings up very good points here. This seems to be the model that many people are going to when developing large systems. This would also help in maintaning the the system. Wayne On Mon, 23 Mar 1998, Darren King wrote: > > ...in fact, I want to bring in the IP code from contrib as part of > > the core yet... > > Would be nice if stuff like that (and the money and geometrics) could be > compiled in in the same manner that Apache is a basic web server that lets > you pick and choose modules/features you want to build into it. > > I don't know how big of a performance boost it provides in the cache, but > removing the functions associated with the char types shrank the pg_proc > table from 906 to 842 entries or a bit over 7%. > > Want to shrink it further? Of those remaining 842, _230_ are for the geometric > types! Throw in 25 more for the cash/money functions. Bloat city if you > never use these things. Thirty percent could be moved out to contrib and > not missed by most postgres users. > > I think a reasonable goal is to provide an sql server that meets the current sql > standard with the possibility of having other types and functionality available > as modules. These modules could be made into the template1 at compile time > or made and installed on a per-database basis. Make your server and database > with whatever you want in it. > > Why force others to have functionality 'x', 'y' and 'z' when they only want 'y'? > > darrenk >
Darren King wrote:
>
> Would be nice if stuff like that (and the money and geometrics) could be
> compiled in in the same manner that Apache is a basic web server that lets
> you pick and choose modules/features you want to build into it.
>
> I don't know how big of a performance boost it provides in the cache, but
> removing the functions associated with the char types shrank the pg_proc
> table from 906 to 842 entries or a bit over 7%.
>
> Want to shrink it further? Of those remaining 842, _230_ are for the geometric
> types! Throw in 25 more for the cash/money functions. Bloat city if you
> never use these things. Thirty percent could be moved out to contrib and
> not missed by most postgres users.
>
> I think a reasonable goal is to provide an sql server that meets the current sql
> standard with the possibility of having other types and functionality available
> as modules. These modules could be made into the template1 at compile time
> or made and installed on a per-database basis. Make your server and database
> with whatever you want in it.
The problem with the contrib stuff is that most users find it too
difficult to dig around in that dir and make and install stuff. The
"contrib" name also give me the feeling that this is unsupported
stuff/beta/not-to-be-used-in-production/to-be-removed etc.
The nicest thing would be if contrib was changed to "modules", and
everything was compiled and installed in /usr/local/pgsql/modules/.
Then the user could install them by typing "INSMOD ORACLE" and then
/usr/local/pgsql/modules/oracle/insmod.sql would be executed and
install shared libraries and sql commands. "RMMOD ORACLE" would
do the opposite. Just like Linux modules.
Perhaps it would even be possible to autoload modules if the modules
directories contains a file with commands/functions listed, which
would be searched automagically...
This is the idea:
psql-> SET MODULES TO AUTOLOAD;
NOTICE: 100 Modules will now load automagically.
psql-> SELECT MYFUNKYFUNC('hello');
NOTICE: 202 Unknown function 'MYFUNKYFUNC(text)'
NOTICE: 100 Module 'MYFUNCTIONS' loaded.
myfunkyfunc
-------------------
the word is 'hello'
(1 row)
psql-> INSMOD ORACLE;
NOTICE: 100 Module 'ORACLE' loaded.
NOTICE: 110 Module description: Oracle(tm) compatability module. Version
1.0.
psql-> LSMOD;
NOTICE: 100 MYFUNCTIONS ORACLE
psql-> RMMOD VERBOSE MYFUNCTIONS;
NOTICE: 100 Module 'MYFUNCTIONS' removed.
NOTICE: 120 Functions removed: Myfunkyfunc(text) Myotherfunc(int)
Mylastfunc(float)
NOTICE: 120 Commands removed: Myfunkycommand
Is it possible to register commands dynamically in the parser?
/* m */
Mattias Kregert wrote: > > Darren King wrote: > > > > Would be nice if stuff like that (and the money and geometrics) could be > > compiled in in the same manner that Apache is a basic web server that lets > > you pick and choose modules/features you want to build into it. > > > > I don't know how big of a performance boost it provides in the cache, but > > removing the functions associated with the char types shrank the pg_proc > > table from 906 to 842 entries or a bit over 7%. > > > > Want to shrink it further? Of those remaining 842, _230_ are for the geometric > > types! Throw in 25 more for the cash/money functions. Bloat city if you > > never use these things. Thirty percent could be moved out to contrib and > > not missed by most postgres users. > > > > I think a reasonable goal is to provide an sql server that meets the current sql > > standard with the possibility of having other types and functionality available > > as modules. These modules could be made into the template1 at compile time > > or made and installed on a per-database basis. Make your server and database > > with whatever you want in it. > > The problem with the contrib stuff is that most users find it too > difficult to dig around in that dir and make and install stuff. The > "contrib" name also give me the feeling that this is unsupported > stuff/beta/not-to-be-used-in-production/to-be-removed etc. > > The nicest thing would be if contrib was changed to "modules", and > everything was compiled and installed in /usr/local/pgsql/modules/. > Then the user could install them by typing "INSMOD ORACLE" and then > /usr/local/pgsql/modules/oracle/insmod.sql would be executed and > install shared libraries and sql commands. "RMMOD ORACLE" would > do the opposite. Just like Linux modules. The difference here is that the entire Linux kernel (modules, "standard" code, etc)must be memory resident at all times. This is not the case with the majority of unix systems out there. Most systems have copy on write pages, filesystem caching and memory paging. The combined effect of these is that unused features do not stay resident in memory, they are sent to the swap, or even discarded and read in from the executable. So this said, I believe there are things that can be done to help this process along. If every feature is compiled to its respective object files and then these files are linked together into one executable, a page containing a desired feature might also contain unneeded code. If instead, the different features are compiled to libraries and then these libraries are linked to the "main" application to create the executable, then each feature will start on a fresh page, which can help keep the minimum number of pages resident, even though keeping the whole program resident now takes more pages. Ocie Mitchell