pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedRe: [HACKERS] char types gone.
23+ messages / 11 participants
[nested] [flat]
* Re: [HACKERS] char types gone.
@ 1970-01-01 00:00 Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
0 siblings, 1 reply; 23+ messages in thread
From: Zeugswetter Andreas @ 1970-01-01 00:00 UTC (permalink / raw)
To: 'The Hermit Hacker' <scrappy@hub.org>; +Cc: 'pgsql-hackers@hub.org' <pgsql-hackers@hub.org>
The Hermit Hacker wrote:
>> > 1. Regression tests make very extensive use of char16. Seems to
>> > me that these should be changed to a name. Same for tutorial and
>> > any other example references in the code. Seem ok?
>>
>> ** down sinks the mast of the old postquel, there, can you see it blink
>> in the deep green water ? ** ** nostalgia on my face ** I think I forgot
>> to mention my nicest hobby, sailing **
>
> Okay, this one has me...what benefit is there to char16 over
>char(16)? Why, in the first place, was it implemented as char16 anyway?
char16 was there before varlena's got implemented, the basis for char(16).
There is no significant advantage of char16 over char(16) any more.
As for "down sinks the mast"...so far as I've been able to tell,
we have *never* removed anything that wasn't replaced by a better way of
doing it (time travel with triggers)...we didn't leave anyone floundering
for a solution to it, we provided it...but now, its not forced on
*everyone*, just on those databases/tables that require it...
Same functionality, better performance...
** up raises the ulralight carbon ultra high speed mast, I like that streamline,
of course for this the old wooden one had to go ;-) **
This was never intended as a critique, I think it is good that char2-16 goes.
Of course I stick to my real message of this thread:
replace the char16 stuff in the tutorial and the regression tests with char(16)
or even varchar(16) but not with name.
Andreas
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1970-01-01 00:00 Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
0 siblings, 0 replies; 23+ messages in thread
From: Zeugswetter Andreas @ 1970-01-01 00:00 UTC (permalink / raw)
To: 'Bruce Momjian' <maillist@candle.pha.pa.us>; +Cc: 'pgsql-hackers@hub.org' <pgsql-hackers@hub.org>
Bruce wrote:
>>
>> You seem to be getting me wrong, right from the start. I appreciate your work on removing
>> char2-char16. I also think it is the correct step. You have the hackers behind you, the discussion was
>> about 2 - 3 weeks ago. I was part of it. There are three things that will need documentation:
>> 1. the replacement for char16 is char(16)
>> 2. char(16) gives and ignores trailing blanks
>
>I don't think this is true.
Hmm ? I am puzzeled. Of course this is true, it has to be, it is standard:
test=> create table chartest (a char(16));
test=> insert into chartest values ('Andreas');
test=> select a || '<' from chartest;
?column?
-----------------
Andreas <
(1 row)
test=> select a || '<' from chartest where a='Andreas';
?column?
-----------------
Andreas <
(1 row)
Andreas
^ permalink raw reply [nested|flat] 23+ messages in thread
* char types gone.
@ 1998-03-21 00:45 Darren King <darrenk@insightdist.com>
0 siblings, 2 replies; 23+ messages in thread
From: darrenk@insightdist.com @ 1998-03-21 00:45 UTC (permalink / raw)
To: pgsql-hackers
Have managed to delete char2,4,8 and 16. The char16 was tricky
since it was still one of the builtins. Removed fine everywhere
but the bootstrap code. Had to leave a dummy entry in the Procid
array so all of the types after char16 would be indexed correctly.
Could remove this dummy by moving types 21-30 down one, but that
would entail renumbering the catalog. With that in mind, I can
live with a filler entry in an array. Heaven knows there are bigger
and badder hacks elsewhere in the code dying to be discovered. :)
Three points now...regression tests, docs and interfaces.
1. Regression tests make very extensive use of char16. Seems to
me that these should be changed to a name. Same for tutorial and
any other example references in the code. Seem ok?
2. I'll take my best shot at the docs.
3. Also take a look/see at the interfaces that reference the char16.
Perhaps would be better for me to contact the maintainers of those
interfaces as they would know what to do better than I.
Once I do one and two, I'll submit the patch.
darrenk
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-23 15:57 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
parent: Darren King <darrenk@insightdist.com>
1 sibling, 0 replies; 23+ messages in thread
From: Thomas G. Lockhart @ 1998-03-23 15:57 UTC (permalink / raw)
To: Darren King <darrenk@insightdist.com>; +Cc: pgsql-hackers
> Have managed to delete char2,4,8 and 16.
> Three points now...regression tests, docs and interfaces.
>
> 1. Regression tests make very extensive use of char16. Seems to
> me that these should be changed to a name. Same for tutorial and
> any other example references in the code. Seem ok?
Any reason not to use "text" for these cases? Or even varchar()? "name"
is probably really only an internal Postgres type. We should have a
regression test for it if we don't already. Let me know if you want me
to help...
> 2. I'll take my best shot at the docs.
Where? The man pages or the sgml sources? I'm shooting for getting the
sgml sources right, and obsoleting the man page _sources_, regenerating
them from the sgml instead.
- Tom
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-23 16:59 The Hermit Hacker <scrappy@hub.org>
parent: Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
0 siblings, 0 replies; 23+ messages in thread
From: The Hermit Hacker @ 1998-03-23 16:59 UTC (permalink / raw)
To: Zeugswetter Andreas <andreas.zeugswetter@telecom.at>; +Cc: 'pgsql-hackers@hub.org' <pgsql-hackers@hub.org>
On Mon, 23 Mar 1998, Zeugswetter Andreas wrote:
> As for "down sinks the mast"...so far as I've been able to tell,
> we have *never* removed anything that wasn't replaced by a better way of
> doing it (time travel with triggers)...we didn't leave anyone floundering
> for a solution to it, we provided it...but now, its not forced on
> *everyone*, just on those databases/tables that require it...
>
> Same functionality, better performance...
>
> ** up raises the ulralight carbon ultra high speed mast, I like that streamline,
> of course for this the old wooden one had to go ;-) **
Okay...just checking. I've heard one major complaint about PostgreSQL in
the past concerning the fact that we are just gutting it and "taking the
Postgres out of PostgreSQL", which I feel is an unfair assessment...
As your analogy puts it above, we've replaced key components of the old
"wooden, three mast'r" with a more sleek and streamlined "carbon fiber
mast"...but that new mast holds the same sails, just gets us to the finish
line faster...
If anyone feels that we've removed something that was really unique and
not replacedit with something better/faster, or provided a work around,
please let us know...in most cases, there is alot of discussion both here,
and in a private list, over whether we go forward with a modification or
not, especially something that is part of the *base* structure of the
system.
We have an *Open* development forum here...if you don't like the route
something is (or appears to be) going, let us know...give us strong
arguements for/against...but don't wait until the discussion is done and
everyone is in agreement before popping up...:(
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-23 20:39 Darren King <darrenk@insightdist.com>
0 siblings, 0 replies; 23+ messages in thread
From: darrenk@insightdist.com @ 1998-03-23 20:39 UTC (permalink / raw)
To: pgsql-hackers
> > Have managed to delete char2,4,8 and 16.
> > Three points now...regression tests, docs and interfaces.
> >
> > 1. Regression tests make very extensive use of char16. Seems to
> > me that these should be changed to a name. Same for tutorial and
> > any other example references in the code. Seem ok?
>
> Any reason not to use "text" for these cases? Or even varchar()? "name"
> is probably really only an internal Postgres type. We should have a
> regression test for it if we don't already. Let me know if you want me
> to help...
I think the 'name' type should be considered an internal type only and
mentioned as such wherever it is documented. It's only purpose seems
to be for a consistent length to internal names and it does that rather
well. User's would be better served with the other, varlena-based, types.
Any examples I was going to convert from char16 to char(16). There are a
couple of mentions of the char16 struct that will have to be integrated
or changed to reference the varlena struct.
Finally, I'm redoing the char16 regression test for name.
> > 2. I'll take my best shot at the docs.
>
> Where? The man pages or the sgml sources? I'm shooting for getting the
> sgml sources right, and obsoleting the man page _sources_, regenerating
> them from the sgml instead.
Do you want patches against doc/src/sgml/*? The man pages references were
few, so they were easy to change for consistency sake then til they drop
into the bit bucket. Changed a few references in the userguide too.
Only have to tidy up the docs and I'll submit the patch.
darrenk
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-23 21:17 Darren King <darrenk@insightdist.com>
0 siblings, 1 reply; 23+ messages in thread
From: darrenk@insightdist.com @ 1998-03-23 21:17 UTC (permalink / raw)
To: pgsql-hackers
> Okay...just checking. I've heard one major complaint about PostgreSQL in
> the past concerning the fact that we are just gutting it and "taking the
> Postgres out of PostgreSQL", which I feel is an unfair assessment...
>
> As your analogy puts it above, we've replaced key components of the old
> "wooden, three mast'r" with a more sleek and streamlined "carbon fiber
> mast"...but that new mast holds the same sails, just gets us to the finish
> line faster...
>
> If anyone feels that we've removed something that was really unique and
> not replacedit with something better/faster, or provided a work around,
> please let us know...in most cases, there is alot of discussion both here,
> and in a private list, over whether we go forward with a modification or
> not, especially something that is part of the *base* structure of the
> system.
>
> We have an *Open* development forum here...if you don't like the route
> something is (or appears to be) going, let us know...give us strong
> arguements for/against...but don't wait until the discussion is done and
> everyone is in agreement before popping up...:(
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.
darrenk
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-23 22:37 The Hermit Hacker <scrappy@hub.org>
parent: Darren King <darrenk@insightdist.com>
0 siblings, 0 replies; 23+ messages in thread
From: The Hermit Hacker @ 1998-03-23 22:37 UTC (permalink / raw)
To: Darren King <darrenk@insightdist.com>; +Cc: pgsql-hackers
On Mon, 23 Mar 1998, Darren King wrote:
> 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...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-23 23:14 Darren King <darrenk@insightdist.com>
0 siblings, 3 replies; 23+ messages in thread
From: darrenk@insightdist.com @ 1998-03-23 23:14 UTC (permalink / raw)
To: pgsql-hackers
> > 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
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 03:27 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Darren King <darrenk@insightdist.com>
2 siblings, 1 reply; 23+ messages in thread
From: Bruce Momjian @ 1998-03-24 03:27 UTC (permalink / raw)
To: darrenk@insightdist.com; +Cc: pgsql-hackers
> 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)
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 03:45 The Hermit Hacker <scrappy@hub.org>
parent: Bruce Momjian <maillist@candle.pha.pa.us>
0 siblings, 1 reply; 23+ messages in thread
From: The Hermit Hacker @ 1998-03-24 03:45 UTC (permalink / raw)
To: Bruce Momjian <maillist@candle.pha.pa.us>; +Cc: Darren King <darrenk@insightdist.com>; pgsql-hackers
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
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 06:58 Peter T Mount <psqlhack@maidast.demon.co.uk>
parent: The Hermit Hacker <scrappy@hub.org>
0 siblings, 1 reply; 23+ messages in thread
From: Peter T Mount @ 1998-03-24 06:58 UTC (permalink / raw)
To: The Hermit Hacker <scrappy@hub.org>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; Darren King <darrenk@insightdist.com>; pgsql-hackers
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
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 07:12 The Hermit Hacker <scrappy@hub.org>
parent: Peter T Mount <psqlhack@maidast.demon.co.uk>
0 siblings, 0 replies; 23+ messages in thread
From: The Hermit Hacker @ 1998-03-24 07:12 UTC (permalink / raw)
To: Peter T Mount <psqlhack@maidast.demon.co.uk>; +Cc: Bruce Momjian <maillist@candle.pha.pa.us>; Darren King <darrenk@insightdist.com>; pgsql-hackers
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
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 11:01 wward <wward@gwi.net>
parent: Darren King <darrenk@insightdist.com>
2 siblings, 0 replies; 23+ messages in thread
From: wward @ 1998-03-24 11:01 UTC (permalink / raw)
To: Darren King <darrenk@insightdist.com>; +Cc: pgsql-hackers
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
>
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 14:35 Mattias Kregert <matti@algonet.se>
parent: Darren King <darrenk@insightdist.com>
2 siblings, 1 reply; 23+ messages in thread
From: Mattias Kregert @ 1998-03-24 14:35 UTC (permalink / raw)
To: Darren King <darrenk@insightdist.com>; +Cc: pgsql-hackers
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 */
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 15:10 Darren King <darrenk@insightdist.com>
0 siblings, 3 replies; 23+ messages in thread
From: darrenk@insightdist.com @ 1998-03-24 15:10 UTC (permalink / raw)
To: pgsql-hackers
> > 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?
How does the cache really work then? Does one pg disk block map to one buffer?
When you say "the cache is empty for those types.", what do you mean?
darrenk
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 15:52 Darren King <darrenk@insightdist.com>
0 siblings, 1 reply; 23+ messages in thread
From: darrenk@insightdist.com @ 1998-03-24 15:52 UTC (permalink / raw)
To: pgsql-hackers
>
> 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.
Vadim has something very similar to this in the contrib/spi Makefile.
Would be a nice model to follow. I agree with your other comment about
the impression given by "contrib."
Contrib could stay the way it is, for independent contributions, then
have a new directory, "modules", for contributions that are integrated
into the postgres make.
Tonight I will finalize my patch for the char types removal and then
later in the week think more about this idea.
> 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:
>
> Is it possible to register commands dynamically in the parser?
CREATE COMMAND would be a new one. Talk about extensibility! :)
darrenk
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 16:38 The Hermit Hacker <scrappy@hub.org>
parent: Darren King <darrenk@insightdist.com>
0 siblings, 0 replies; 23+ messages in thread
From: The Hermit Hacker @ 1998-03-24 16:38 UTC (permalink / raw)
To: Darren King <darrenk@insightdist.com>; +Cc: pgsql-hackers
On Tue, 24 Mar 1998, Darren King wrote:
> >
> > 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.
>
> Vadim has something very similar to this in the contrib/spi Makefile.
>
> Would be a nice model to follow. I agree with your other comment about
> the impression given by "contrib."
>
> Contrib could stay the way it is, for independent contributions, then
> have a new directory, "modules", for contributions that are integrated
> into the postgres make.
Doing something like an LKM (loadable kernel module) would be,
IMHO, neat, if it could be done seamlessly...we have the loading
capabilities now...but seamlessly would mean that I didn't have to think
about adding it each time I upgraded my server. If you can pull *that*
off, then we might have something to consider.
As long as JoeUser that wants to use the geometric types doesn't
have to think of adding them in to use them, great...I don't want, in 6
months, to realize that I don't have those geometric types installed when
I happen to require them :(
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 17:02 Maarten Boekhold <maartenb@dutepp2.et.tudelft.nl>
parent: Darren King <darrenk@insightdist.com>
2 siblings, 0 replies; 23+ messages in thread
From: Maarten Boekhold @ 1998-03-24 17:02 UTC (permalink / raw)
To: Darren King <darrenk@insightdist.com>; +Cc: pgsql-hackers
On Tue, 24 Mar 1998, Darren King wrote:
> > > 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?
>
> How does the cache really work then? Does one pg disk block map to one buffer?
>
> When you say "the cache is empty for those types.", what do you mean?
I think there's some confusion about which cache is meant. I think the
previous poster (ie. the one before darren) is thinking of processor
cache, be it first level or second level. Darren is probably meaning a
postgresql internal cache....
Maarten
_____________________________________________________________________________
| TU Delft, The Netherlands, Faculty of Information Technology and Systems |
| Department of Electrical Engineering |
| Computer Architecture and Digital Technique section |
| M.Boekhold@et.tudelft.nl |
-----------------------------------------------------------------------------
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 19:01 ocie@paracel.com
parent: Mattias Kregert <matti@algonet.se>
0 siblings, 0 replies; 23+ messages in thread
From: ocie@paracel.com @ 1998-03-24 19:01 UTC (permalink / raw)
To: matti@algonet.se; +Cc: darrenk@insightdist.com; pgsql-hackers
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
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-24 19:17 David Gould <dg@illustra.com>
parent: Darren King <darrenk@insightdist.com>
2 siblings, 0 replies; 23+ messages in thread
From: dg@illustra.com @ 1998-03-24 19:17 UTC (permalink / raw)
To: darrenk@insightdist.com; +Cc: pgsql-hackers
> > > 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%.
No performance impact.
> > > 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?
>
> How does the cache really work then? Does one pg disk block map to one buffer?
>
> When you say "the cache is empty for those types.", what do you mean?
The function cache has one entry for each function in use. If a function has
never been called, then no cache entry is ever created for it. The cache
is organized per function, it is not part of the buffer / page cache so
each entry only takes a few bytes.
-dg
David Gould dg@illustra.com 510.628.3783 or 510.305.9468
Informix Software (No, really) 300 Lakeside Drive Oakland, CA 94612
- Linux. Not because it is free. Because it is better.
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-03-25 02:38 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Darren King <darrenk@insightdist.com>
2 siblings, 0 replies; 23+ messages in thread
From: Bruce Momjian @ 1998-03-25 02:38 UTC (permalink / raw)
To: darrenk@insightdist.com; +Cc: pgsql-hackers
> > 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?
>
> How does the cache really work then? Does one pg disk block map to one buffer?
>
> When you say "the cache is empty for those types.", what do you mean?
I believe the buffer page cache does load in those types if they are in
the same page as a requsted type, but the relation/function caches only
store in requested relations/functions, as far as I know.
--
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)
^ permalink raw reply [nested|flat] 23+ messages in thread
* Re: [HACKERS] char types gone.
@ 1998-04-26 04:03 Bruce Momjian <maillist@candle.pha.pa.us>
parent: Darren King <darrenk@insightdist.com>
1 sibling, 0 replies; 23+ messages in thread
From: Bruce Momjian @ 1998-04-26 04:03 UTC (permalink / raw)
To: darrenk@insightdist.com; +Cc: pgsql-hackers
Re-applied this patch, now that 6.3.* is closed.
>
>
> Have managed to delete char2,4,8 and 16. The char16 was tricky
> since it was still one of the builtins. Removed fine everywhere
> but the bootstrap code. Had to leave a dummy entry in the Procid
> array so all of the types after char16 would be indexed correctly.
> Could remove this dummy by moving types 21-30 down one, but that
> would entail renumbering the catalog. With that in mind, I can
> live with a filler entry in an array. Heaven knows there are bigger
> and badder hacks elsewhere in the code dying to be discovered. :)
>
> Three points now...regression tests, docs and interfaces.
>
> 1. Regression tests make very extensive use of char16. Seems to
> me that these should be changed to a name. Same for tutorial and
> any other example references in the code. Seem ok?
>
> 2. I'll take my best shot at the docs.
>
> 3. Also take a look/see at the interfaces that reference the char16.
> Perhaps would be better for me to contact the maintainers of those
> interfaces as they would know what to do better than I.
>
> Once I do one and two, I'll submit the patch.
>
> darrenk
>
>
--
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)
^ permalink raw reply [nested|flat] 23+ messages in thread
end of thread, other threads:[~1998-04-26 04:03 UTC | newest]
Thread overview: 23+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1970-01-01 00:00 Re: [HACKERS] char types gone. Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-23 16:59 ` The Hermit Hacker <scrappy@hub.org>
1970-01-01 00:00 Re: [HACKERS] char types gone. Zeugswetter Andreas <andreas.zeugswetter@telecom.at>
1998-03-21 00:45 char types gone. Darren King <darrenk@insightdist.com>
1998-03-23 15:57 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-04-26 04:03 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-03-23 20:39 Re: [HACKERS] char types gone. Darren King <darrenk@insightdist.com>
1998-03-23 21:17 Re: [HACKERS] char types gone. Darren King <darrenk@insightdist.com>
1998-03-23 22:37 ` The Hermit Hacker <scrappy@hub.org>
1998-03-23 23:14 Re: [HACKERS] char types gone. Darren King <darrenk@insightdist.com>
1998-03-24 03:27 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-03-24 03:45 ` The Hermit Hacker <scrappy@hub.org>
1998-03-24 06:58 ` Peter T Mount <psqlhack@maidast.demon.co.uk>
1998-03-24 07:12 ` The Hermit Hacker <scrappy@hub.org>
1998-03-24 11:01 ` wward <wward@gwi.net>
1998-03-24 14:35 ` Mattias Kregert <matti@algonet.se>
1998-03-24 19:01 ` ocie@paracel.com
1998-03-24 15:10 Re: [HACKERS] char types gone. Darren King <darrenk@insightdist.com>
1998-03-24 17:02 ` Maarten Boekhold <maartenb@dutepp2.et.tudelft.nl>
1998-03-24 19:17 ` David Gould <dg@illustra.com>
1998-03-25 02:38 ` Bruce Momjian <maillist@candle.pha.pa.us>
1998-03-24 15:52 Re: [HACKERS] char types gone. Darren King <darrenk@insightdist.com>
1998-03-24 16:38 ` The Hermit Hacker <scrappy@hub.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox