> > 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

Mon, 23 Mar 1998 18:14:58 -0500
darrenk@insightdist.com (Darren King)
Re: [HACKERS] char types gone.
> 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)

Mon, 23 Mar 1998 22:27:50 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] char types gone.
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 


Mon, 23 Mar 1998 23:45:01 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] char types gone.
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


Tue, 24 Mar 1998 06:58:36 +0000 (GMT)
Peter T Mount <psqlhack@maidast.demon.co.uk>
Re: [HACKERS] char types gone.
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 


Tue, 24 Mar 1998 03:12:02 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] char types gone.
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
> 


Tue, 24 Mar 1998 06:01:04 -0500 (EST)
wward <wward@gwi.net>
Re: [HACKERS] char types gone.
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 */

Tue, 24 Mar 1998 15:35:31 +0100
Mattias Kregert <matti@algonet.se>
Re: [HACKERS] char types gone.
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

Tue, 24 Mar 1998 11:01:56 -0800 (PST)
ocie@paracel.com
Re: [HACKERS] char types gone.