Thread: PL/java?
What do you think of having java as a procedural language available in PG? It seems like java has many advantages. I'm just wondering if people have thoughts or ideas on this, and if someone is actually working on it, that would be cool.
probably a bad idea. From what I've heard the speed of your java program is wholely dependent on the speed of your vm (and most aren't that quick). Although it would be nice to have just to say we have it and mysql doesn't (then again mysql doesn't have a whole lot of things that pgsql already has). Geoff -----Original Message----- From: Dr. Evil [mailto:drevil@sidereal.kz] Sent: Saturday, August 25, 2001 7:38 PM To: pgsql-general@postgresql.org Subject: [GENERAL] PL/java? What do you think of having java as a procedural language available in PG? It seems like java has many advantages. I'm just wondering if people have thoughts or ideas on this, and if someone is actually working on it, that would be cool. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
> I'm just wondering if people have thoughts or ideas on this, and if
> someone is actually working on it, that would be cool.
Why would that be cool? Because it's an OO language? If that's
the criteria for cool, check out pl/Ruby. It's a pure OO language (java
isn't) and is a joy to work with, but YMMV. -sc
--
Sean Chittenden
Attachment
"Gowey, Geoffrey" <ggowey@rxhope.com> writes: > probably a bad idea. From what I've heard the speed of your java program is > wholely dependent on the speed of your vm (and most aren't that quick). > Although it would be nice to have just to say we have it and mysql doesn't > (then again mysql doesn't have a whole lot of things that pgsql already > has). Well, compiled Java code can't be that much slower than PL/pgSQL code or TCL. both of which work fine for lots of people... I've though about doing this. It's definitely doable, but here are some gotchas: * The JVM is multithreaded, while backends are single-threaded. This could open up a big can of worms if you're not careful. On platforms with different libc's for threaded/nonthreaded code, you'd have to get the linking right. * In order to be useful, you'd need to write a JNI wrapper for the SPI libraries. Again, threading issues may apply. It's an interesting project, but not one I've had time to look at yet. -Doug -- Free Dmitry Sklyarov! http://www.freesklyarov.org/ We will return to our regularly scheduled signature shortly.
See the TODO list under Java. There are some emails discussing the
issues:
http://candle.pha.pa.us/cgi-bin/pgtodo?java
>
> What do you think of having java as a procedural language available in
> PG? It seems like java has many advantages.
>
> I'm just wondering if people have thoughts or ideas on this, and if
> someone is actually working on it, that would be cool.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> probably a bad idea. From what I've heard the speed of your java program is
> wholely dependent on the speed of your vm (and most aren't that quick).
> Although it would be nice to have just to say we have it and mysql doesn't
> (then again mysql doesn't have a whole lot of things that pgsql already
> has).
Can someone explain why the addition of a stored procedural language for
MySQL made it as a Slashdot headline? Do our new features make it
there?
http://slashdot.org/article.pl?sid=01/08/24/1253228&mode=nested
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> probably a bad idea. From what I've heard the speed of your java program is
> wholely dependent on the speed of your vm (and most aren't that quick).
> Although it would be nice to have just to say we have it and mysql doesn't
> (then again mysql doesn't have a whole lot of things that pgsql already
> has).
Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL:
http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes: > Can someone explain why the addition of a stored procedural language for > MySQL made it as a Slashdot headline? Probably because /. uses MySQL (poor benighted fools ;) -Doug -- Free Dmitry Sklyarov! http://www.freesklyarov.org/ We will return to our regularly scheduled signature shortly.
> Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: > > http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Yeah, I've had a few developers show it to me... the best part of this is though, when I tried to post a comment, I got a MySQL database error. ::grin:: At anyrate, it looks like a load of FUD from a bad marketing department (at least Microsoft lies well). -sc -- Sean Chittenden
Attachment
----- Original Message ----- From: "Sean Chittenden" <sean-pgsql-general@chittenden.org> To: "Bruce Momjian" <pgman@candle.pha.pa.us> Cc: "Gowey, Geoffrey" <ggowey@rxhope.com>; "'Dr. Evil'" <drevil@sidereal.kz>; <pgsql-general@postgresql.org> Sent: Saturday, August 25, 2001 11:48 PM Subject: Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
> probably a bad idea. From what I've heard the speed of your java > program is wholely dependent on the speed of your vm (and most > aren't that quick). Although it would be nice to have just to say > we have it and mysql doesn't (then again mysql doesn't have a whole > lot of things that pgsql already has). PG has no competition from MySQL. MySQL finally got a procedural language, but it's perl! perl is in many ways a terrible PL. Basically, if you are using a database for any kind of real stuff where data integrity and reliability are important, you need a strongly-typed language. PL/pgsql is actually a greal language for this. Far better than perl. Anyway... yeah, I have heard that a lot of java vms are not fast, but a lot of the time fast isn't as important as solid and correct, and java lends itself to solid, correct programming better than most other languages.
Hi Sean, We can always ask them to change things. The thing which strike me as wrong the most is the stability issue with PostgreSQL. I've only very rarely heard reports by anyone saying MySQL was more stable than PostgreSQL for them. Most of the rest I think can be justified in one way or another. If anyone else can see things blatantly wrong on that page, email me about them and I'll ask Monty (the MySQL guy) to please change/remove/fix them. :-) Regards and best wishes, Justin Clift Sean Chittenden wrote: > > > Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: > > > > http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html > > Yeah, I've had a few developers show it to me... the best part > of this is though, when I tried to post a comment, I got a MySQL > database error. ::grin:: At anyrate, it looks like a load of FUD from > a bad marketing department (at least Microsoft lies well). -sc > > -- > Sean Chittenden > > ------------------------------------------------------------------------ > Part 1.2Type: application/pgp-signature > > ------------------------------------------------------------------------ > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
> We can always ask them to change things. The thing which > strike me as wrong the most is the stability issue with > PostgreSQL. I've only very rarely heard reports by anyone > saying MySQL was more stable than PostgreSQL for them. Yeah, saying mysql is more stable than postgres is a complete joke from my own experiences and those around me. Also, I think people move from mysql to postgres, rarely the other way round.. - Andrew
Sean Chittenden wrote: >>Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: >> >> http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html >> > > Yeah, I've had a few developers show it to me... the best part >of this is though, when I tried to post a comment, I got a MySQL >database error. ::grin:: At anyrate, it looks like a load of FUD from >a bad marketing department (at least Microsoft lies well). -sc > One might also add as a 'con' for mysql...spelling. As horribly frequent the spelling errors are on this page, one might reasonable assume that you could... selected * frm tabloid wear valued be 'huh?'; -d -- >:> I may have the information you need and I may choose only HTML. It's up to you.
You guys shouldn't even be worrying about this. Five years from now, MySQL will be a much more mature product, but the way I see it now is this: MySQL: Great for message boards (Slashdot), information retrieval (an on-line phone directory that's mostly static), or other lightweight applications. PG7.1: Great for doing more commercial type things: inventories, accounting, and business in general, but it does lack some of the high-end DB features, particularly replication and clustering, and also some performance optimizations, which make it not quite in the big-leagues yet. Oracle: Great for everything beyond PG7.1. MS-SQL: Use this one if you desperately need Western currency and want to "lose" some plutonium! PG7.2: It finally has replication! This makes it a strong competitor to Oracle for most applications. Why is replication so important? If the data you are dealing with are valuable, you simply cannot trust them to one machine. Machines catch on fire, buildings burn down, earthquakes happen, lightning strikes. A disaster can happen any time, anywhere. The only solution to this is replication. Until PG has it, it can't be trusted with really valuable data. One thing which I would like to see in addition to replication is an enhanced WAL mechanism. Right now WAL only writes to a log file. That's fine, but I can see two other things that WAL could do very easily, which would be great for financial users, or others who deal with valuable data: One is sending the tuple, as a string, off to another server somewhere to be logged, perhaps in another DB of some kind. That way, when Server #1 gets struck by lightning, no problem, not a single transaction has been lost. This wouldn't take any major mods to the WAL system; if someone would tell me where to look in the code, I'll do it myself. The second WAL change would be to allow WAL to send output to a plain old dot matrix printer. Yes, it's a primitive thing to do, but again, if you are dealing with financial transactions, sometimes it's a wonderful thing to be able to have them in a human-readable read-only format. No amount of elite hacking can undo something which has been printed. This technique, as primitive as it sounds, is used all over the place. Ever notice that when you put your ATM card in the machine, you often hear a printer going? Everything is logged the old-fashioned way. Again, if someone will point me to the place in the WAL code where it has the tuple and it wants to write it out, I'll make these mods myself.
Justin Clift writes: > If anyone else can see things blatantly wrong on that page, email me > about them and I'll ask Monty (the MySQL guy) to please > change/remove/fix them. > > > http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Many of these advantages can easily interpreted as disadvantages. For example: * MySQL has more API to other languages and is supported by more programs than PostgreSQL. See section D Contributed Programs. => MySQL has 6 Perl modules, 5 ODBC drivers, and 4 C++ interfaces. PostgreSQL concentrates its efforts on making one driver work best for all users. * There are far moore books in print on MySQL than on PostgreSQL. O'Reilly, Sams, Que, and New Riders are all major publishers with books about MySQL. => MySQL is so hard to understand and poorly documented, a plethora of books had to come out before anyone could use it. * All MySQL features is also documented in the MySQL on-line manual because when a feature is implemented, the MySQL developers are required to document it before it's included in the source. => blah... :-) * MySQL has support for tables without transactions for applications that need all speed they can get. => MySQL is not a fully transactional database system. * MySQL has support for 3 different table handles that support transactions => In PostgreSQL you don't need to think about which table type to choose because one works for all. * MySQL has internal support for text search. See section 6.8 MySQL Full-text Search. => PostgreSQL has a number of different full text search solutions available, or users can plug in their own. * You can access many databases from the same connection (depending of course on your privileges). => PostgreSQL does not allow you to access more than one database per connection. This makes the system much safer and allows for more robust design. * MySQL is coded from the start with multi-threading while PostgreSQL uses processes. => PostgreSQL is coded from the start with multi-processing while MySQL uses threads. Threads have historically led to much more bug-prone programs and are poorly supported on many operating systems. If one thread crashes your whole server goes down. * MySQL has a much more sophisticated privilege system than PostgreSQL. => MySQL has a much more complicated privilege system than PostgreSQL. * MySQL employs the table handler concept and is the only relational database we know of built around this concept. => MySQL employs a table handler concept, which makes your code much less SQL compliant and makes MySQL harder to learn. * Tools to repair and optimize MyISAM tables (the most common MySQL table type). => In MySQL you have to repair your tables manually if corruption occurs. PostgreSQL is coded so that corruption cannot occur. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
At 03:21 PM 8/26/01 +0200, Peter Eisentraut wrote: >* There are far moore books in print on MySQL than on PostgreSQL. >O'Reilly, Sams, Que, and New Riders are all major publishers with books >about MySQL. > >=> MySQL is so hard to understand and poorly documented, a plethora of >books had to come out before anyone could use it. I disagree. MySQL was quite easy to understand (furthermore it was limited in what it could do :) ). And it's well documented. The limitations were documented too - that part I liked very much. As for the justifications for their limitations, some valid and the rest not that important to me - ignorable. I found postgresql harder to understand when I first tried it (Postgres95). And performance was terrible then, so I had to revert to MySQL. Then there were these adhoc pgsql commands you run from the command shell which didn't work for me (createdb etc). I had turned on access controls in pg_hba which broke most of the command shell scripts which assumed no access controls, and the PGSQL documentation assumed that most people would use the command shell scripts/programs... >* MySQL has internal support for text search. See section 6.8 MySQL >Full-text Search. > >=> PostgreSQL has a number of different full text search solutions >available, or users can plug in their own. Yah, I hope you realised you used a similar argument against MySQL for their many APIs :). >* You can access many databases from the same connection (depending of >course on your privileges). > >=> PostgreSQL does not allow you to access more than one database per >connection. This makes the system much safer and allows for more robust >design. How does that makes things safer etc etc? I believe that this is a genuine limitation. I hope the developers are honest why this limitation exists. There are probably valid and good reasons for this limitation but I don't think "safer and more robust" is a good one. If it really is, then it reduces my confidence level in Postgresql's access control design/internals. >* MySQL has a much more sophisticated privilege system than PostgreSQL. > >=> MySQL has a much more complicated privilege system than PostgreSQL. Just different to me. >* Tools to repair and optimize MyISAM tables (the most common MySQL table >type). > >=> In MySQL you have to repair your tables manually if corruption occurs. >PostgreSQL is coded so that corruption cannot occur. I sure hope so. But I also hope that people look at things objectively and not blind themselves in defense of what they hold dear. Taking a long view of things, MySQL is likely to have some design and usage issues with the multiple ways of handling what they call transactions. They may have to do some pruning soon and leave only the good branches. Postgresql is better for what I currently need to do. I'm glad it has improved a lot. Cheerio, Link.
Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
>> => PostgreSQL does not allow you to access more than one database per
>> connection. This makes the system much safer and allows for more robust
>> design.
> How does that makes things safer etc etc? I believe that this is a genuine
> limitation.
It's unlikely that the "one DB per connection" limitation will ever
change. What is likely to happen (for 7.3, with any luck) is that we
will implement SQL92-compatible schema naming within the traditional
Postgres notion of a database. More than likely, most installations
will then migrate to keeping all their stuff in multiple schemas within
one big database, and the issue will cease to be a problem in practice
even though the technical limitation is still there.
I have no doubt that MySQL's comparison page will keep pointing to this
issue as a fatal limitation of PG long after it ceases to be a problem,
however ;-)
>> * Tools to repair and optimize MyISAM tables (the most common MySQL table
>> type).
>>
>> => In MySQL you have to repair your tables manually if corruption occurs.
>> PostgreSQL is coded so that corruption cannot occur.
> I sure hope so.
A more accurate way of stating this is "we prefer to spend our
development time on eliminating bugs, not on devising tools to clean up
after bugs".
regards, tom lane
Re: MySQL's (false?) claims... (was: Re: PL/java?)
From
teg@redhat.com (Trond Eivind Glomsrød)
Date:
Peter Eisentraut <peter_e@gmx.net> writes: > Justin Clift writes: > > > If anyone else can see things blatantly wrong on that page, email me > > about them and I'll ask Monty (the MySQL guy) to please > > change/remove/fix them. > > > > > http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html > > Many of these advantages can easily interpreted as disadvantages. For > example: > > * MySQL has more API to other languages and is supported by more programs > than PostgreSQL. See section D Contributed Programs. > > => MySQL has 6 Perl modules, 5 ODBC drivers, and 4 C++ interfaces. > PostgreSQL concentrates its efforts on making one driver work best for all > users. For interfaces, it's best to have only one, and a good one (like one DBD module for perl, one JDBC interface for Java, one python module implementing the Python DB API (there are several Pg ones available here)). But this didn't just focus on APIs. > * There are far moore books in print on MySQL than on PostgreSQL. > O'Reilly, Sams, Que, and New Riders are all major publishers with books > about MySQL. > > => MySQL is so hard to understand and poorly documented, a plethora of > books had to come out before anyone could use it. That is a ridiculous claim. More documentation is good - like how to apply the different scenarios and by different authors. From "Foo in 24 hours" to "Data mining with bar". > * All MySQL features is also documented in the MySQL on-line manual > because when a feature is implemented, the MySQL developers are required > to document it before it's included in the source. > > => blah... :-) The MySQL documentation is actually rather nice (not saying that the PostgreSQL isn't). > * MySQL has support for tables without transactions for applications that > need all speed they can get. > > => MySQL is not a fully transactional database system. It defaults to this as well, AFAIR. > * MySQL has internal support for text search. See section 6.8 MySQL > Full-text Search. > > => PostgreSQL has a number of different full text search solutions > available, or users can plug in their own. Weren't you the one preaching the wonders of "one way to do it" (API-wise) above? > * You can access many databases from the same connection (depending of > course on your privileges). > > => PostgreSQL does not allow you to access more than one database per > connection. This makes the system much safer and allows for more robust > design. Sometimes, you'd like to anyway ;) The person doing the bugzilla port would even like to have multi-DB operations (and split tables, with parts of the query running on each one). > => PostgreSQL is coded from the start with multi-processing while MySQL > uses threads. Threads have historically led to much more bug-prone > programs and are poorly supported on many operating systems. If one > thread crashes your whole server goes down. > > * MySQL has a much more sophisticated privilege system than PostgreSQL. > > => MySQL has a much more complicated privilege system than > PostgreSQL. There is a difference between what must be done and what can be done. E.g. you can use Emacs quite comofortably as a very powerful editor without knowing much lisp. You can do anything you want if you need to. > * MySQL employs the table handler concept and is the only relational > database we know of built around this concept. > > => MySQL employs a table handler concept, which makes your code much less > SQL compliant and makes MySQL harder to learn. Do you have to use it, or is it something you can choose to take advantage of? > * Tools to repair and optimize MyISAM tables (the most common MySQL table > type). > > => In MySQL you have to repair your tables manually if corruption occurs. > PostgreSQL is coded so that corruption cannot occur. You sound like H.R. That's not a compliment. -- Trond Eivind Glomsrød Red Hat, Inc.
Me writes: > > > > http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html > > Many of these advantages can easily interpreted as disadvantages. For > example: I hope people aren't taking that feature comparison page as seriously as they took my parody of it. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> >* You can access many databases from the same connection (depending of > >course on your privileges). > > > >=> PostgreSQL does not allow you to access more than one database per > >connection. This makes the system much safer and allows for more robust > >design. > > How does that makes things safer etc etc? I believe that this is a genuine > limitation. > > I hope the developers are honest why this limitation exists. There are > probably valid and good reasons for this limitation but I don't think > "safer and more robust" is a good one. If it really is, then it reduces my > confidence level in Postgresql's access control design/internals. There are actually good reasons, the first being that the postgresql view is that databases are distinct entities (as opposed to schemas which will hopefully get there eventually) and as such it makes no sense to cross-db query. Right now, it's more of a limitation due to the fact that permissions to prevent object creation aren't there and that schemas aren't there, but once that's done I don't think this is much of a limitation anymore. In addition, there are questions about authentication that I think are tricky here, such as, we query a view, it uses another db, what user/password should be used? should we query the user? does the user even *know* what other db this view uses and why he's being prompted for a password? Every client program (even random libpq ones) potentially need to be able to handle an authentication request in response to a query? It's not a clear cut win.
On Sun, 26 Aug 2001, Peter Eisentraut wrote: > Many of these advantages can easily interpreted as disadvantages. For > example: Have you ever considered a career in marketting? > => In MySQL you have to repair your tables manually if corruption occurs. > PostgreSQL is coded so that corruption cannot occur. Ho ho. This one is my favorite. -sam
As strange as this may sound, I had to do a cross database query at my last job. It involved moving information from our e-commerce database into the accounting system database. While there may have been another way of handling it, this did allow me to handle the move solely within MSSQL and not have to schedule something like a seperate program to run. (Which I'd have to do to accomplish this in PGSQL currently.) Stephan Szabo wrote: > > > >* You can access many databases from the same connection (depending of > > >course on your privileges). > > > > > >=> PostgreSQL does not allow you to access more than one database per > > >connection. This makes the system much safer and allows for more robust > > >design. > > > > How does that makes things safer etc etc? I believe that this is a genuine > > limitation. > > > > I hope the developers are honest why this limitation exists. There are > > probably valid and good reasons for this limitation but I don't think > > "safer and more robust" is a good one. If it really is, then it reduces my > > confidence level in Postgresql's access control design/internals. > > There are actually good reasons, the first being that the > postgresql view is that databases are distinct entities (as opposed to > schemas which will hopefully get there eventually) and as such it makes no > sense to cross-db query. Right now, it's more of a limitation due to the > fact that permissions to prevent object creation aren't there and that > schemas aren't there, but once that's done I don't think this is much > of a limitation anymore. > > In addition, there are questions about authentication that I think are > tricky here, such as, we query a view, it uses another db, what > user/password should be used? should we query the user? does the user > even *know* what other db this view uses and why he's being prompted for > a password? Every client program (even random libpq ones) potentially > need to be able to handle an authentication request in response to a > query? It's not a clear cut win. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Digital Wokan wrote: >As strange as this may sound, I had to do a cross database query at my >last job. It involved moving information from our e-commerce database >into the accounting system database. While there may have been another >way of handling it, this did allow me to handle the move solely within >MSSQL and not have to schedule something like a seperate program to >run. (Which I'd have to do to accomplish this in PGSQL currently.) > Why couldn't you open a connection to each db and do a middle temporary table if needed? I think it's a matter of which angle you saw the problem. -d -- >:> I may have the information you need and I may choose only HTML. It's up to you.
> If you can afford to learn another language, and get some time to put it = > to > practical use, I suggest that you take a closer look at Java... or IMHO, = > atleast > don't knock it until you have substancial reasoning. I agree. java is a great language. The biggest problem with java? Lack of portability! Yes, that's right, it's not portable! If you are using Linux or a commercial OS of some kind, you have great java support, but under FreeBSD or OpenBSD? Good luck getting Java 2 to work! But it's still a great language and I'm moving all my stuff from PHP to Java.
You make a good point about Java not being "portable" (the JVM not being fully portable anyways). That could certainly be enough reason to not benefit the PostgreSQL community as a whole. It _is_ a shame that Java 2 hasn't made it over to other platforms yet. Although, I haven't thought about it much, but I'm not sure I see any advantages of using Java over PG/plsql. Other than streamlining _some_ development since developers in a Java shop would know Java, I don't see any language-specific advantages. (Oh by the way, my two previous posts have been delayed since I sent them from the wrong email address) -Knight -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Dr. Evil Sent: Sunday, August 26, 2001 1:03 PM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? > If you can afford to learn another language, and get some time to put it = > to > practical use, I suggest that you take a closer look at Java... or IMHO, = > atleast > don't knock it until you have substancial reasoning. I agree. java is a great language. The biggest problem with java? Lack of portability! Yes, that's right, it's not portable! If you are using Linux or a commercial OS of some kind, you have great java support, but under FreeBSD or OpenBSD? Good luck getting Java 2 to work! But it's still a great language and I'm moving all my stuff from PHP to Java. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
> You make a good point about Java not being "portable" (the JVM not > being fully portable anyways). That could certainly be enough reason > to not benefit the PostgreSQL community as a whole. It _is_ a shame > that Java 2 hasn't made it over to other platforms yet. It will make it to the other platforms eventually, I hope. It's a shame that Sun's "write once, compile once, run everywhere" promise is just marketing to some extent. > Although, I haven't thought about it much, but I'm not sure I see > any advantages of using Java over PG/plsql. Other than streamlining > _some_ development since developers in a Java shop would know Java, > I don't see any language-specific advantages. pl/pgsql is a great language, I agree. However, java has some tremendous advantages. The big one is its classes. I needed to do some DES encryption within the PG database. Well, there's no DES function in PG, or in pl/pgsql, so I had to write it as a C function and then link it in. Sure, that works, but the point is, if we had pl/java, I would just call java.security.encryption.des() (or whatever it is) and it would be there. Right now I need to do some public key stuff. I could try to link that all in in C, but that would be a huge pain. The java standard classes do just about everything. pl/pgsql will never come close to that. Also, java is object oriented and more convenient for writing larger things.
I agree that there could be quite a few circumstances where you would want to utilize the class libraries. I'm doing a lot of PKI myself, and I could see how painful it would be to waste time trying in C, when Java _does_ really offer a lot. -Kevin -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Dr. Evil Sent: Sunday, August 26, 2001 4:52 PM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? > You make a good point about Java not being "portable" (the JVM not > being fully portable anyways). That could certainly be enough reason > to not benefit the PostgreSQL community as a whole. It _is_ a shame > that Java 2 hasn't made it over to other platforms yet. It will make it to the other platforms eventually, I hope. It's a shame that Sun's "write once, compile once, run everywhere" promise is just marketing to some extent. > Although, I haven't thought about it much, but I'm not sure I see > any advantages of using Java over PG/plsql. Other than streamlining > _some_ development since developers in a Java shop would know Java, > I don't see any language-specific advantages. pl/pgsql is a great language, I agree. However, java has some tremendous advantages. The big one is its classes. I needed to do some DES encryption within the PG database. Well, there's no DES function in PG, or in pl/pgsql, so I had to write it as a C function and then link it in. Sure, that works, but the point is, if we had pl/java, I would just call java.security.encryption.des() (or whatever it is) and it would be there. Right now I need to do some public key stuff. I could try to link that all in in C, but that would be a huge pain. The java standard classes do just about everything. pl/pgsql will never come close to that. Also, java is object oriented and more convenient for writing larger things. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
David Ford wrote: > > Sean Chittenden wrote: > > >>Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: > >> > >> http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html > >> > > > > Yeah, I've had a few developers show it to me... the best part > >of this is though, when I tried to post a comment, I got a MySQL > >database error. ::grin:: At anyrate, it looks like a load of FUD from > >a bad marketing department (at least Microsoft lies well). -sc > > > > One might also add as a 'con' for mysql...spelling. As horribly As you will see below, I think the "spelling" is a waste of CPU and time. > frequent the spelling errors are on this page, one might reasonable > assume that you could... You can "reasonable assume" incorrect spelling is OK if you are a total moron. Note: "reasonable assume" should be "reasonably assume" for the non illiterate. > > selected * frm tabloid wear valued be 'huh?'; Boy! You would have to be very "spelling challenged" to come up with that. > > -d > > -- > >:> > I may have the information you need and I may choose only HTML. It's up to you. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) If your first language is not english I can understand why your grammar and spelling are so poor. I consider myself to be poor at spelling but I rarely make mistakes when programming, and when I do I get an error then I can fix it. If you have a routine that tries to figure out what you want, it may give unexpected results and you will have difficulty fixing the problem. Write your code properly and it will be easier to fix if there is an error. Guy Fraser -- There is a fine line between genius and lunacy, fear not, walk the line with pride. Not all things will end up as you wanted, but you will certainly discover things the meek and timid will miss out on.
Guy Fraser wrote: >As you will see below, I think the "spelling" is a waste of CPU and >time. > I don't use CPU time for spelling :) >>...frequent the spelling errors are on this page, one might reasonable >>assume that you could... >> > >You can "reasonable assume" incorrect spelling is OK if you are a total >moron. > >Note: "reasonable assume" should be "reasonably assume" for the non >illiterate. > Yes, I'm rather red-faced about that typo. I fully intended to put a 'y' there, not an 'e'. >>selected * frm tabloid wear valued be 'huh?'; >> > >Boy! You would have to be very "spelling challenged" to come up with >that. > Actually that statement was half aimed at spelling and half a pot shot at the article. Only a few people got the pun. David -- >:> I may have the information you need and I may choose only HTML. It's up to you.
> I'm just wondering if people have thoughts or ideas on this, and if
> someone is actually working on it, that would be cool.
Why would that be cool? Because it's an OO language? If that's
the criteria for cool, check out pl/Ruby. It's a pure OO language (java
isn't) and is a joy to work with, but YMMV. -sc
--
Sean Chittenden
Attachment
how that can come, that table locking is faster than versioning? from how i understand versioning it can't be slower. and saying that "possible access problems" with table can be avoided be specially designing application. God! i must design specially for mysql, being locking whole tables. this page shows that they are low-end even in the mind. they didn't implemet constraints/subselects/views/triggers/full joins, but they've got packed bases and compressed client/server protocol! wow. must be cool. personally, when i tried 7.0.2, with triggers/constraints/views and other cool stuff (transactions!) i said to myself "yep, that's the db you need". and now, whatever they say, when i hear somebody doing billing system (!) on mysql, i just shrug my shoulders. in russian it called "everybody goes insane his own way". btw, what's related to in-memory quick db, what prevents you from creating memory filesystem and put postgres dbs there? in *bsd it's not a problem, on linux i believe too... On Sun, Aug 26, 2001 at 02:29:55PM +1000, Justin Clift wrote: > We can always ask them to change things. The thing which strike me as > > Sean Chittenden wrote: > > > Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: > > > > > > http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html > > > > Yeah, I've had a few developers show it to me... the best part -- Denis A. Doroshenko [GPRS engineer] .-. _|_ | [Omnitel Ltd., T.Sevcenkos st. 25, Vilnius, Lithuania] | | _ _ _ .| _ | [Phone: +370 9863486 E-mail: d.doroshenko@omnitel.net] |_|| | || |||(/_|_
yeah, by the way, doing dump/restore not such a bad thing, as mysql may say. supporting old stuff is sometimes horrible. look at micro$oft, which carries all the sh.t through its OSs... -- Denis A. Doroshenko [GPRS engineer] .-. _|_ | [Omnitel Ltd., T.Sevcenkos st. 25, Vilnius, Lithuania] | | _ _ _ .| _ | [Phone: +370 9863486 E-mail: d.doroshenko@omnitel.net] |_|| | || |||(/_|_
I keep hearing all this talk about Java being slow, and how compiled Java is nearly as slow as interpreted languages... If Java was _that_ slow, do you think it would be powering a majority of the Enterprise level sites out there? Java is really more than just hype. Surely it isn't nearly as fast as native optimized C/C++. But there are numerous advantages to the language. If you can afford to learn another language, and get some time to put it to practical use, I suggest that you take a closer look at Java... or IMHO, atleast don't knock it until you have substancial reasoning. -Kevin -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Gowey, Geoffrey Sent: Saturday, August 25, 2001 5:09 PM To: 'Dr. Evil'; pgsql-general@postgresql.org Subject: RE: [GENERAL] PL/java? probably a bad idea. From what I've heard the speed of your java program is wholely dependent on the speed of your vm (and most aren't that quick). Although it would be nice to have just to say we have it and mysql doesn't (then again mysql doesn't have a whole lot of things that pgsql already has). Geoff -----Original Message----- From: Dr. Evil [mailto:drevil@sidereal.kz] Sent: Saturday, August 25, 2001 7:38 PM To: pgsql-general@postgresql.org Subject: [GENERAL] PL/java? What do you think of having java as a procedural language available in PG? It seems like java has many advantages. I'm just wondering if people have thoughts or ideas on this, and if someone is actually working on it, that would be cool. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
> > Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: > > http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html > Yeah, I've had a few developers show it to me... the best part > of this is though, when I tried to post a comment, I got a MySQL > database error. ::grin:: At anyrate, it looks like a load of FUD from > a bad marketing department... It is more of the same that we have seen from MySQL over the years. Each of the items are unsubstantiated or plain wrong: 1) "Generally much faster". Actually, "generally much slower" in production environments, where there are multiple clients, simultaneous selects and updates, and complex queries. 2) "Code is much more stable". Unsubstantiated. And there are architectural reasons to believe that PG is more robust under failures. But that opinion might be the reason behind the MyS historically slow release cycle. 3) "Works on more platforms". Wrong. I count ~20 platforms in the MySQL list, and we have ~30 in the PG list. The list is tabulated differently (e.g., HPUX shows up multiple times) but no matter how you slice it, you can't reach that conclusion. 4) "Works better on Windows". Unsubstantiated, and it does not specify what "better" means. 5) "Has more API" (sic) But the number of supported languages is about the same. So?? 6) "Works on 24/7 systems". Unsubstantiated, and a narrow focus on vacuum issues is certainly not a complete justification for this conclusion regarding MySQL. 7) "A working, tested replication feature". Failed on well known large sites such as SourceForge. 8) "2 testing suites ... more sofisticated (sic) than anything have seen from PostgreSQL". Unsubstantiated, and the crashme test has historically contained gross errors in representing SQL standards and test results. 9) "More books". Enough books? 10) "More support for the standard ODBC functions". Maybe, but not substantiated. The crashme test does not actually run ODBC, but rather tries to execute ODBC-like functions from within the backend directly. Not relevant. 11) "Has support for tables without transactions". Hmm. Could rephrase as "by default, MySQL has only optional support for the most basic of RDBMS features, and this only in the last few months." "... for applications that need all speed they can get". Actually only true for applications with one or a few users, and only under limited conditions. Nothing like real life, eh? 12) "3 different table handles". So? The first two didn't work?? Got to go for now... - Thomas
>> -----Original Message----- >> From: Dr. Evil [mailto:drevil@sidereal.kz] >> Sent: Saturday, August 25, 2001 7:38 PM >> To: pgsql-general@postgresql.org >> Subject: [GENERAL] PL/java? >> >> >> What do you think of having java as a procedural language available in >> PG? It seems like java has many advantages. >> >> I'm just wondering if people have thoughts or ideas on this, and if >> someone is actually working on it, that would be cool. >""Gowey, Geoffrey"" <ggowey@rxhope.com> wrote in message news:E15F4B031E17D5118B18009027F67927DAC0@SERVER... > probably a bad idea. From what I've heard the speed of your java program is > wholely dependent on the speed of your vm (and most aren't that quick). > Although it would be nice to have just to say we have it and mysql doesn't > (then again mysql doesn't have a whole lot of things that pgsql already > has). > > Geoff This was a major issue in 1996. It's been solved for several years now, but the perception of Java having a speed problem remains. Java stored procedures are the #1 most-desired-by-me feature for PostgreSQL. Oracle and Sybase are examples of databases that have this feature already. (Strangely, Microsoft's database doesn't have it :-) Marshall Spight
On Sun, 26 Aug 2001, Alex Knight wrote: > I keep hearing all this talk about Java being slow, and how compiled Java is > nearly as slow as interpreted languages... If Java was _that_ slow, do you > think it would be powering a majority of the Enterprise level sites out there? Have you ever actually used Java on an enterprise-level application? Ever see the Tomcat webserver? It uses 100MB of memory, drives the load on our server up to 8, and doesn't serve nearly as fast apache. Do you really want that in your database? It isn't slow just because of the interpretation, or the byte-code, or the structure, or even the overhead. It's slow because every application must have a hulking JVM sitting in memory, bringing even fast machines to their knees in short order. Not even perl, with everything it does, is that big, nor does it affect a machine so adversely. Ever wonder why most JVM's stay in memory after they start? Compare the speed of Oracle 8 with 8i if you don't believe me. The stability is also much worse. Ever see a JVM on any platform that didn't crash if you looked at it cockeyed? Ever really trust the garbage collection? I don't. I've found a memory leak in IBM developed java libraries. Gotta restart that app every once in a while to reclaim system resources it gobbled up and never gave back. Merits of the language notwithstanding, I'd rather not have a buggy, still under development (depreciating everything under the sun with every new iteration) JVM parasite in my DB. So... you want a larger, slower, memory leaking, more crash-prone DB just to have java support? Personally, I hope the Postgres developers don't make the same mistake as the Oracle developers. Yuck. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. Thomas INN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830 | | Email: sthomas@townnews.com AIM : trifthen | | Web : hamster.lee.net | | | | "Most of our lives are about proving something, either to | | ourselves or to someone else." | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
On Thu, 30 Aug 2001, Marshall Spight wrote: > This was a major issue in 1996. It's been solved for several years now, but > the perception of Java having a speed problem remains. > > Java stored procedures are the #1 most-desired-by-me feature for PostgreSQL. > Oracle and Sybase are examples of databases that have this feature already. > (Strangely, Microsoft's database doesn't have it :-) Its not a perception. Java is still a dog. Again, see my mail message of few days ago regarding faking PL/java using pl/perl ;) -alex
have you ever seen/benchmarked the orion application server? it's a java web and appserver and their benchmarks have it outperforming ASP code which runs natively inside of win2k. also take a look at jetty which is a beautiful and tiny web server designed for embedding in java apps that also runs servlets and jsps. both are 100% pure java. just because tomcat doesn't cut the mustard doesn't mean that _nothing_ else does. rjsjr > -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Shaun Thomas > Sent: Friday, August 31, 2001 11:28 AM > To: Alex Knight > Cc: Gowey, Geoffrey; 'Dr. Evil'; pgsql-general@postgresql.org > Subject: Re: [GENERAL] PL/java? > > > On Sun, 26 Aug 2001, Alex Knight wrote: > > > I keep hearing all this talk about Java being slow, and > how compiled Java is > > nearly as slow as interpreted languages... If Java was > _that_ slow, do you > > think it would be powering a majority of the Enterprise > level sites out there? > > Have you ever actually used Java on an enterprise-level > application? Ever > see the Tomcat webserver? It uses 100MB of memory, drives > the load on our > server up to 8, and doesn't serve nearly as fast apache. > Do you really > want that in your database? > > It isn't slow just because of the interpretation, or the > byte-code, or the > structure, or even the overhead. It's slow because every > application must > have a hulking JVM sitting in memory, bringing even fast > machines to their > knees in short order. Not even perl, with everything it > does, is that > big, nor does it affect a machine so adversely. Ever > wonder why most > JVM's stay in memory after they start? > > Compare the speed of Oracle 8 with 8i if you don't believe me. The > stability is also much worse. Ever see a JVM on any > platform that didn't > crash if you looked at it cockeyed? Ever really trust the garbage > collection? I don't. I've found a memory leak in IBM > developed java > libraries. Gotta restart that app every once in a while to reclaim > system resources it gobbled up and never gave back. > > Merits of the language notwithstanding, I'd rather not have > a buggy, still > under development (depreciating everything under the sun > with every new > iteration) JVM parasite in my DB. > > So... you want a larger, slower, memory leaking, more > crash-prone DB just > to have java support? > > Personally, I hope the Postgres developers don't make the > same mistake as > the Oracle developers. Yuck. > > -- > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-+ > | Shaun M. Thomas INN Database Programmer > | > | Phone: (309) 743-0812 Fax : (309) 743-0830 > | > | Email: sthomas@townnews.com AIM : trifthen > | > | Web : hamster.lee.net > | > | > | > | "Most of our lives are about proving something, > either to | > | ourselves or to someone else." > | > | -- Anonymous > | > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-+ > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to > majordomo@postgresql.org >
Even when compiled into bytecode, Java is much slower than C/C++ when bechmarked... However, Java does what I need it to. But just to clarify, the "myth" continues on about "slowness." -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Marshall Spight Sent: Thursday, August 30, 2001 11:52 AM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? >> -----Original Message----- >> From: Dr. Evil [mailto:drevil@sidereal.kz] >> Sent: Saturday, August 25, 2001 7:38 PM >> To: pgsql-general@postgresql.org >> Subject: [GENERAL] PL/java? >> >> >> What do you think of having java as a procedural language available in >> PG? It seems like java has many advantages. >> >> I'm just wondering if people have thoughts or ideas on this, and if >> someone is actually working on it, that would be cool. >""Gowey, Geoffrey"" <ggowey@rxhope.com> wrote in message news:E15F4B031E17D5118B18009027F67927DAC0@SERVER... > probably a bad idea. From what I've heard the speed of your java program is > wholely dependent on the speed of your vm (and most aren't that quick). > Although it would be nice to have just to say we have it and mysql doesn't > (then again mysql doesn't have a whole lot of things that pgsql already > has). > > Geoff This was a major issue in 1996. It's been solved for several years now, but the perception of Java having a speed problem remains. Java stored procedures are the #1 most-desired-by-me feature for PostgreSQL. Oracle and Sybase are examples of databases that have this feature already. (Strangely, Microsoft's database doesn't have it :-) Marshall Spight ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
...
> Java stored procedures are the #1 most-desired-by-me feature for PostgreSQL.
> Oracle and Sybase are examples of databases that have this feature already.
...
How does java manage its resources when it is an embedded component?
When it is standalone, the Sun JDK seems to want to have a fixed maximum
amount of memory, as an example. I'd hate to have a nice 10MB PostgreSQL
backend calling a 256MB jvm to execute a simple small program.
The other embedded languages we have start small and can grow
dynamically. But I don't know what is possible in this regard for
Java...
- Thomas
I'm very sorry that you've had bad experiences with Java. Apparently they seem tainted. Part of your problem is that you were using inexpensive java application servers (tomcat) that, IMHO, need plenty of optimization and fine tuning before they can be used to successfully deploy an enterprise application. Apps like tomcat are _great_ for development, but anything more than that, and you will most definately run into situations like you described. Ofcourse, there are probably those that slip through the cracks, and still have a successful deployment of these lower-end app servers and still survive with hundreds of thousands of hits per day. It is generally wiser to split the webservers from the appservers; that will save on memory footprints from each respectively. That alone can give each machine a specific task to accomplish... generally more efficiently. But I would assume you know this. Using something like WebLogic, WebSphere, or Orion would be a wiser approach. For the company with the low budget, Orion is only something like $2000, and it has full J2EE support, including EJBs, etc. Try finding that kind of richness in Tomcat. Also, Orion takes up only 40-50mb at start, which is really fairly reasonable; ram is cheap anyways... a server that has to perform complicated algorithms to a large audience but has hardly any ram shouldn't be on the internet anyways; unless it can handle it. I feel that you don't really have enough experience with _java_ to judge it accurately. Frankly, the JVM is quite small nowadays, considering the amount of base classes that sit in memory much of the time. And the JVMs are really much faster these days. Java is still slow for 2 reasons: 1) Developers who don't optimize their code as they write it, 2) Bytecode interpretation is and probably never will be as fast as something like C/C++. But it certainly isn't the JVM itself slowing it down because of some "extended memory" that it lives in. Any reasonable server should have absolutely no problems if the jvm is implemented _properly_ (which many packages do not do), etc. If you're comparing Java to perl, yes, certainly it's a bit more of a beast, but perl quite simply can't keep up in speed and feature richness (when was the last time you secured your perl code in a redistributable fashion?) Oracle 8 and Oracle 8i are really two different dbs. I've personally seen much improvement with 8i, and in comparisons between legacy oracle8 dbs versus oracle8i containing the same live database structure and data (10 million+ rows) we've seen IMPROVEMENT in our query timings. It isn't java affecting 8i in a negative way unless ofcourse you are actually embedding java code, in which case, could easily be your code affecting the db if not watched carefully. The only time garbage collection has been a problem, is when software companies start tampering with the jvm or create their own pseudo garbage collection, like IBM does with WebSphere (*cough*). WebSphere can be truely dangerous. Adding java support in postgresql does not mean that it will affect users in any way that, by default, will not even compile in support for it. How will that affect users who feel no need for it? Furthermore, I strongly disagree that adding Java support will make it "larger, slower, memory leaking, more crash-prone". Like any products, languages, or even situation, there are well written devices, and poorly written devices. Your bad experiences with Tomcat have surely stained you against java. If you have the time, I suggest you go download a free copy of Orion (orionserver.com) and see how incredible true enterprise J2EE can be. The only mistake the developers can make is poorly implementing the jvm, but most certainly not Java itself. I've been working on architecting and building enterprise level sites and applications for nearly 8 years now, and I've seen too many people try to implement perl cgi websites for enterprise sites and watch them choke and crawl to their knees because of poor system resource handling, lack of scalability, etc... I most certainly don't consider a single webserver with an appserver and tiny database to be enterprise level either (not that I'm inferring you said it was). -Knight -----Original Message----- From: Shaun Thomas [mailto:sthomas@townnews.com] Sent: Friday, August 31, 2001 9:28 AM To: Alex Knight Cc: Gowey, Geoffrey; 'Dr. Evil'; pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? On Sun, 26 Aug 2001, Alex Knight wrote: > I keep hearing all this talk about Java being slow, and how compiled Java is > nearly as slow as interpreted languages... If Java was _that_ slow, do you > think it would be powering a majority of the Enterprise level sites out there? Have you ever actually used Java on an enterprise-level application? Ever see the Tomcat webserver? It uses 100MB of memory, drives the load on our server up to 8, and doesn't serve nearly as fast apache. Do you really want that in your database? It isn't slow just because of the interpretation, or the byte-code, or the structure, or even the overhead. It's slow because every application must have a hulking JVM sitting in memory, bringing even fast machines to their knees in short order. Not even perl, with everything it does, is that big, nor does it affect a machine so adversely. Ever wonder why most JVM's stay in memory after they start? Compare the speed of Oracle 8 with 8i if you don't believe me. The stability is also much worse. Ever see a JVM on any platform that didn't crash if you looked at it cockeyed? Ever really trust the garbage collection? I don't. I've found a memory leak in IBM developed java libraries. Gotta restart that app every once in a while to reclaim system resources it gobbled up and never gave back. Merits of the language notwithstanding, I'd rather not have a buggy, still under development (depreciating everything under the sun with every new iteration) JVM parasite in my DB. So... you want a larger, slower, memory leaking, more crash-prone DB just to have java support? Personally, I hope the Postgres developers don't make the same mistake as the Oracle developers. Yuck. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. Thomas INN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830 | | Email: sthomas@townnews.com AIM : trifthen | | Web : hamster.lee.net | | | | "Most of our lives are about proving something, either to | | ourselves or to someone else." | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
Well spoken... -Knight -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Robert J. Sanford, Jr. Sent: Friday, August 31, 2001 4:15 PM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? have you ever seen/benchmarked the orion application server? it's a java web and appserver and their benchmarks have it outperforming ASP code which runs natively inside of win2k. also take a look at jetty which is a beautiful and tiny web server designed for embedding in java apps that also runs servlets and jsps. both are 100% pure java. just because tomcat doesn't cut the mustard doesn't mean that _nothing_ else does. rjsjr > -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Shaun Thomas > Sent: Friday, August 31, 2001 11:28 AM > To: Alex Knight > Cc: Gowey, Geoffrey; 'Dr. Evil'; pgsql-general@postgresql.org > Subject: Re: [GENERAL] PL/java? > > > On Sun, 26 Aug 2001, Alex Knight wrote: > > > I keep hearing all this talk about Java being slow, and > how compiled Java is > > nearly as slow as interpreted languages... If Java was > _that_ slow, do you > > think it would be powering a majority of the Enterprise > level sites out there? > > Have you ever actually used Java on an enterprise-level > application? Ever > see the Tomcat webserver? It uses 100MB of memory, drives > the load on our > server up to 8, and doesn't serve nearly as fast apache. > Do you really > want that in your database? > > It isn't slow just because of the interpretation, or the > byte-code, or the > structure, or even the overhead. It's slow because every > application must > have a hulking JVM sitting in memory, bringing even fast > machines to their > knees in short order. Not even perl, with everything it > does, is that > big, nor does it affect a machine so adversely. Ever > wonder why most > JVM's stay in memory after they start? > > Compare the speed of Oracle 8 with 8i if you don't believe me. The > stability is also much worse. Ever see a JVM on any > platform that didn't > crash if you looked at it cockeyed? Ever really trust the garbage > collection? I don't. I've found a memory leak in IBM > developed java > libraries. Gotta restart that app every once in a while to reclaim > system resources it gobbled up and never gave back. > > Merits of the language notwithstanding, I'd rather not have > a buggy, still > under development (depreciating everything under the sun > with every new > iteration) JVM parasite in my DB. > > So... you want a larger, slower, memory leaking, more > crash-prone DB just > to have java support? > > Personally, I hope the Postgres developers don't make the > same mistake as > the Oracle developers. Yuck. > > -- > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-+ > | Shaun M. Thomas INN Database Programmer > | > | Phone: (309) 743-0812 Fax : (309) 743-0830 > | > | Email: sthomas@townnews.com AIM : trifthen > | > | Web : hamster.lee.net > | > | > | > | "Most of our lives are about proving something, > either to | > | ourselves or to someone else." > | > | -- Anonymous > | > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-+ > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to > majordomo@postgresql.org > ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
On Fri, 31 Aug 2001, Alex Knight wrote: > It is generally wiser to split the webservers from the appservers; > that will save on memory footprints from each respectively. That alone > can give each machine a specific task to accomplish... generally more > efficiently. But I would assume you know this. And it is wise to split database from middleware, and not try to saddle PostgreSQL with requirements to support Java in-process. _IF_ java stored procedures are implemented, it should be via something like a) oracle's extproc (start a separate process to load the function) b) some of perl java tools (they start a jdk in a separate process and communicate with it using RMI). Problem with java-pgsql integration is the threads model: Java really really wants threads. Postgres doesn't do threads. So if most simple way is attempted, you will incur overhead of starting up JVM for each backend (a few seconds as opposed to milliseconds) and non-shared 30M of memory per backend (as opposed to currently <3 megs of non-shared memory per backend). > Using something like WebLogic, WebSphere, or Orion would be a wiser > approach. For the company with the low budget, Orion is only something > like $2000, and it has full J2EE support, including EJBs, etc. Try > finding that kind of richness in Tomcat. Also, Orion takes up only > 40-50mb at start, which is really fairly reasonable; ram is cheap > anyways... a server that has to perform complicated algorithms to a > large audience but has hardly any ram shouldn't be on the internet > anyways; unless it can handle it. _ONLY_ 40-50Mb?! Egads, I'm hard pressed to find any other piece of (non-windows, non-java) software that takes 40-50M just to start up! I worked with both CrapLogic and CrapSphere. Weblogic takes 20-60 seconds to start up on P3-800, that, IMHO, is ridiculous. It is not only issue of memory, its easy to throw memory at the problem, its an issue of _incremental use_ of memory. As you scale > I feel that you don't really have enough experience with _java_ to > judge it accurately. Frankly, the JVM is quite small nowadays, > considering the amount of base classes that sit in memory much of the > time. And the JVMs are really much faster these days. Java is still > slow for 2 reasons: 1) Developers who don't optimize their code as > they write it, 2) Bytecode interpretation is and probably never will > be as fast as something like C/C++. But it certainly isn't the JVM > itself slowing it down because of some "extended memory" that it lives > in. Any reasonable server should have absolutely no problems if the > jvm is implemented _properly_ (which many packages do not do), etc. If > you're comparing Java to perl, yes, certainly it's a bit more of a > beast, but perl quite simply can't keep up in speed and feature > richness (when was the last time you secured your perl code in a > redistributable fashion?) _WHY_ the heck do all base classes need to be in memory all the time? Why are they so huge? Libc is _far far_ smaller, and libstdc++ is tiny compared to all the java standard library. You know what the answer to it is: Because they are ALL written in java, as opposed to more sane languages like perl which handcode their "standard libraries" or the most important pieces of them in C. Perl is far faster than java in about any practical application I did. Again, the issue is not speed of JVM versus PP (perl virtual machine), if you did number crunching in perl and java, they would probably be at par. Its an issue of standard libraries. They are _horribly slow_. Perl's hashtables are a very nice piece of optimized C code. Java's hashtables are written in Java. Need I say more? Java's AWT was a dog. Swing is a dog and a half, because they reimplemented all the things that are commonly done in C in Java. > The only mistake the developers can make is poorly implementing the > jvm, but most certainly not Java itself. I've been working on > architecting and building enterprise level sites and applications for > nearly 8 years now, and I've seen too many people try to implement > perl cgi websites for enterprise sites and watch them choke and crawl > to their knees because of poor system resource handling, lack of > scalability, etc... I most certainly don't consider a single webserver > with an appserver and tiny database to be enterprise level either (not > that I'm inferring you said it was). You cannot compare a perl CGI script and a J2EE server. Its like comparing a webserver you wrote yourself vs apache! There are application servers (or more closely, code libraries) for perl that match what J2EE provides. -- Alex Pilosov | http://www.acedsl.com/home.html CTO - Acecape, Inc. | AceDSL:The best ADSL in the world 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) New York, NY 10018 |
Not really. Yes, AWT sucks. Yes, Swing sucks. Java's gui code can be INCREDIBLY lame. But for server-side situations, Java can be incredibly scalable. I wasn't comparing a perl CGI script and a J2EE server, other than saying perl simply doesn't offer what J2EE does. Furthermore, I've seen more newbies write perl cgi scripts in an enterprise environment and break the site the minute traffic picks up. IMHO, scalability is incredibly important, and perl leaves that out often. Even with Fast-CGI style servers, perl sucks. Perl is great for admin interfaces, or low to medium traffic sites. -----Original Message----- From: Alex Pilosov [mailto:alex@pilosoft.com] Sent: Friday, August 31, 2001 7:35 PM To: Alex Knight Cc: pgsql-general@postgresql.org Subject: [WAY OT] Re: [GENERAL] PL/java? On Fri, 31 Aug 2001, Alex Knight wrote: > It is generally wiser to split the webservers from the appservers; > that will save on memory footprints from each respectively. That alone > can give each machine a specific task to accomplish... generally more > efficiently. But I would assume you know this. And it is wise to split database from middleware, and not try to saddle PostgreSQL with requirements to support Java in-process. _IF_ java stored procedures are implemented, it should be via something like a) oracle's extproc (start a separate process to load the function) b) some of perl java tools (they start a jdk in a separate process and communicate with it using RMI). Problem with java-pgsql integration is the threads model: Java really really wants threads. Postgres doesn't do threads. So if most simple way is attempted, you will incur overhead of starting up JVM for each backend (a few seconds as opposed to milliseconds) and non-shared 30M of memory per backend (as opposed to currently <3 megs of non-shared memory per backend). > Using something like WebLogic, WebSphere, or Orion would be a wiser > approach. For the company with the low budget, Orion is only something > like $2000, and it has full J2EE support, including EJBs, etc. Try > finding that kind of richness in Tomcat. Also, Orion takes up only > 40-50mb at start, which is really fairly reasonable; ram is cheap > anyways... a server that has to perform complicated algorithms to a > large audience but has hardly any ram shouldn't be on the internet > anyways; unless it can handle it. _ONLY_ 40-50Mb?! Egads, I'm hard pressed to find any other piece of (non-windows, non-java) software that takes 40-50M just to start up! I worked with both CrapLogic and CrapSphere. Weblogic takes 20-60 seconds to start up on P3-800, that, IMHO, is ridiculous. It is not only issue of memory, its easy to throw memory at the problem, its an issue of _incremental use_ of memory. As you scale > I feel that you don't really have enough experience with _java_ to > judge it accurately. Frankly, the JVM is quite small nowadays, > considering the amount of base classes that sit in memory much of the > time. And the JVMs are really much faster these days. Java is still > slow for 2 reasons: 1) Developers who don't optimize their code as > they write it, 2) Bytecode interpretation is and probably never will > be as fast as something like C/C++. But it certainly isn't the JVM > itself slowing it down because of some "extended memory" that it lives > in. Any reasonable server should have absolutely no problems if the > jvm is implemented _properly_ (which many packages do not do), etc. If > you're comparing Java to perl, yes, certainly it's a bit more of a > beast, but perl quite simply can't keep up in speed and feature > richness (when was the last time you secured your perl code in a > redistributable fashion?) _WHY_ the heck do all base classes need to be in memory all the time? Why are they so huge? Libc is _far far_ smaller, and libstdc++ is tiny compared to all the java standard library. You know what the answer to it is: Because they are ALL written in java, as opposed to more sane languages like perl which handcode their "standard libraries" or the most important pieces of them in C. Perl is far faster than java in about any practical application I did. Again, the issue is not speed of JVM versus PP (perl virtual machine), if you did number crunching in perl and java, they would probably be at par. Its an issue of standard libraries. They are _horribly slow_. Perl's hashtables are a very nice piece of optimized C code. Java's hashtables are written in Java. Need I say more? Java's AWT was a dog. Swing is a dog and a half, because they reimplemented all the things that are commonly done in C in Java. > The only mistake the developers can make is poorly implementing the > jvm, but most certainly not Java itself. I've been working on > architecting and building enterprise level sites and applications for > nearly 8 years now, and I've seen too many people try to implement > perl cgi websites for enterprise sites and watch them choke and crawl > to their knees because of poor system resource handling, lack of > scalability, etc... I most certainly don't consider a single webserver > with an appserver and tiny database to be enterprise level either (not > that I'm inferring you said it was). You cannot compare a perl CGI script and a J2EE server. Its like comparing a webserver you wrote yourself vs apache! There are application servers (or more closely, code libraries) for perl that match what J2EE provides. -- Alex Pilosov | http://www.acedsl.com/home.html CTO - Acecape, Inc. | AceDSL:The best ADSL in the world 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) New York, NY 10018 |
Also, if we should remove "middleware" from the database, I think we better remove PG/PLSQL, C, and all the other various api's we support. The ability to support Java doesn't turn the database into a middleware whore, it already IS. -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Alex Pilosov Sent: Friday, August 31, 2001 7:35 PM To: Alex Knight Cc: pgsql-general@postgresql.org Subject: [WAY OT] Re: [GENERAL] PL/java? On Fri, 31 Aug 2001, Alex Knight wrote: > It is generally wiser to split the webservers from the appservers; > that will save on memory footprints from each respectively. That alone > can give each machine a specific task to accomplish... generally more > efficiently. But I would assume you know this. And it is wise to split database from middleware, and not try to saddle PostgreSQL with requirements to support Java in-process. _IF_ java stored procedures are implemented, it should be via something like a) oracle's extproc (start a separate process to load the function) b) some of perl java tools (they start a jdk in a separate process and communicate with it using RMI). Problem with java-pgsql integration is the threads model: Java really really wants threads. Postgres doesn't do threads. So if most simple way is attempted, you will incur overhead of starting up JVM for each backend (a few seconds as opposed to milliseconds) and non-shared 30M of memory per backend (as opposed to currently <3 megs of non-shared memory per backend). > Using something like WebLogic, WebSphere, or Orion would be a wiser > approach. For the company with the low budget, Orion is only something > like $2000, and it has full J2EE support, including EJBs, etc. Try > finding that kind of richness in Tomcat. Also, Orion takes up only > 40-50mb at start, which is really fairly reasonable; ram is cheap > anyways... a server that has to perform complicated algorithms to a > large audience but has hardly any ram shouldn't be on the internet > anyways; unless it can handle it. _ONLY_ 40-50Mb?! Egads, I'm hard pressed to find any other piece of (non-windows, non-java) software that takes 40-50M just to start up! I worked with both CrapLogic and CrapSphere. Weblogic takes 20-60 seconds to start up on P3-800, that, IMHO, is ridiculous. It is not only issue of memory, its easy to throw memory at the problem, its an issue of _incremental use_ of memory. As you scale > I feel that you don't really have enough experience with _java_ to > judge it accurately. Frankly, the JVM is quite small nowadays, > considering the amount of base classes that sit in memory much of the > time. And the JVMs are really much faster these days. Java is still > slow for 2 reasons: 1) Developers who don't optimize their code as > they write it, 2) Bytecode interpretation is and probably never will > be as fast as something like C/C++. But it certainly isn't the JVM > itself slowing it down because of some "extended memory" that it lives > in. Any reasonable server should have absolutely no problems if the > jvm is implemented _properly_ (which many packages do not do), etc. If > you're comparing Java to perl, yes, certainly it's a bit more of a > beast, but perl quite simply can't keep up in speed and feature > richness (when was the last time you secured your perl code in a > redistributable fashion?) _WHY_ the heck do all base classes need to be in memory all the time? Why are they so huge? Libc is _far far_ smaller, and libstdc++ is tiny compared to all the java standard library. You know what the answer to it is: Because they are ALL written in java, as opposed to more sane languages like perl which handcode their "standard libraries" or the most important pieces of them in C. Perl is far faster than java in about any practical application I did. Again, the issue is not speed of JVM versus PP (perl virtual machine), if you did number crunching in perl and java, they would probably be at par. Its an issue of standard libraries. They are _horribly slow_. Perl's hashtables are a very nice piece of optimized C code. Java's hashtables are written in Java. Need I say more? Java's AWT was a dog. Swing is a dog and a half, because they reimplemented all the things that are commonly done in C in Java. > The only mistake the developers can make is poorly implementing the > jvm, but most certainly not Java itself. I've been working on > architecting and building enterprise level sites and applications for > nearly 8 years now, and I've seen too many people try to implement > perl cgi websites for enterprise sites and watch them choke and crawl > to their knees because of poor system resource handling, lack of > scalability, etc... I most certainly don't consider a single webserver > with an appserver and tiny database to be enterprise level either (not > that I'm inferring you said it was). You cannot compare a perl CGI script and a J2EE server. Its like comparing a webserver you wrote yourself vs apache! There are application servers (or more closely, code libraries) for perl that match what J2EE provides. -- Alex Pilosov | http://www.acedsl.com/home.html CTO - Acecape, Inc. | AceDSL:The best ADSL in the world 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) New York, NY 10018 | ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
note - i don't work for any of the companies whose products are mentioned below. i have performed evaluations of these products and the support provided when attempting to determine what platform my company's systems should run on. unfortunately, i did not choose orion and i am suffering for it now... some goober blathered thusly: > Have you ever actually used Java on an enterprise-level > application? Ever see the Tomcat webserver? It uses > 100MB of memory, drives the load on our server up to 8, > and doesn't serve nearly as fast apache. Do you really > want that in your database? first - don't complain about java because you or someone in your group/department/company made a poor decision on what tools to use. that's like complaining about mexican food when the only experience you have is eating an out- dated frozen burrito from the 7-11 freezer. when looking at the performance of java you have to take a look at two things - first you have to compare various java implementations against each other and then you have to compare the best java implementations against native c/c++ code. the following link does that. the java tests include tomcat, orion, websphere, and resin. jrun and weblogic were originally included in the testing but were both removed at their companies' request. the tests also compare orion vs microsoft asp running on win2k and iis5. all tests run on the same hardware. what i believe these tests clearly demonstrate is that java is not the problem, the implementation applications based on java is. i also do not believe that tomcat is a fair representation of java performance in that it is intended to be a reference implementation. as such, the code base should sacrifice performance for clarity. http://www.orionserver.com/benchmarks/benchmark.html while not in the benchmark i would also like to recommend jetty as an app server. it is an opensource, 100% java web and application server. in its base form it is "just" a web, servlet, and jsp engine. it does, however, have contributed code providing integration with other j2ee opensource projects such as the JBoss EJB engine. you can find the jetty home page at: http://jetty.mortbay.com/ and then they blathered some more: > Compare the speed of Oracle 8 with 8i if you don't > believe me. The stability is also much worse. Ever > see a JVM on any platform that didn't crash if you > looked at it cockeyed? Ever really trust the garbage > collection? I don't. I've found a memory leak in IBM > developed java libraries. Gotta restart that app > every once in a while to reclaim system resources it > gobbled up and never gave back. some mention was made regarding the performance of the oracle8i application server. well, oracle has realized that their performance was sub-optimal and rectified the situation by licensing the orion server for oracle9i. while money and politics most certainly play a part in any licensing arrangement they must also realize that making customers happy through the performance of their applications will lead to more money. the link to the press release is below. http://www.oracle.com/corporate/press/index.html?759347.html all of that being said... i don't think that the person that started this thread did anything wrong by making the request they did. that is what opensource is all about - contributions, even just contributions of ideas, are welcomed. even so, there are several options that i see for getting it implemented: 1) its an open source project so implement it yourself. while i have never worked on modifying the code base i am extremely confident that the current developers will be more than willing to give you advice and pointers. 2) if #1 is not feasible either because you don't have the time, the inclination, or the experience then you can write a contract that will pay one of the postgres developers to implement it for you. 3) if that isn't feasible you can try to get a volunteer to do so. 4) if that isn't feasible then you either have to live with what you have, go elsewhere, or be quiet. to the person that blathered thusly in response to the request for java: > Merits of the language notwithstanding, I'd rather > not have a buggy, still under development > (depreciating everything under the sun with every > new iteration) JVM parasite in my DB. informed and intelligent debate is good. given that i believe such to be true, i would request that you refrain from blathering such vitriol and uninformed nonsense. not only is it for the good of the people on the list who don't want to hear it but it will also do you good by not telling everyone out there that you are a very silly person that doesn't deal with logic and/or facts. to everyone else on the list - if we all contribute a penny we could probably buy enough burritos from 7-11 to make sure that his hands and mouth are busy for a good long while. rjsjr
Well, mod_perl is not exactly slow... and I believe any JAVA program will be slower than the respective PERL program (there are newbie books for both languages :) But, perhaps you talk WINDOWS? If so, any software on WINDOWS can be slower than any other software on WINDOWS... just because they happen to link so some weird DLL. Daniel >>>"Alex Knight" said: > Not really. > > Yes, AWT sucks. Yes, Swing sucks. Java's gui code can be INCREDIBLY lame. > But for server-side situations, Java can be incredibly scalable. > > I wasn't comparing a perl CGI script and a J2EE server, other than saying > perl simply doesn't offer what J2EE does. Furthermore, I've seen more > newbies > write perl cgi scripts in an enterprise environment and break the site > the minute traffic picks up. > > IMHO, scalability is incredibly important, and perl leaves that out often. > Even with Fast-CGI style servers, perl sucks. Perl is great for admin > interfaces, or low to medium traffic sites. > > -----Original Message----- > From: Alex Pilosov [mailto:alex@pilosoft.com] > Sent: Friday, August 31, 2001 7:35 PM > To: Alex Knight > Cc: pgsql-general@postgresql.org > Subject: [WAY OT] Re: [GENERAL] PL/java? > > > On Fri, 31 Aug 2001, Alex Knight wrote: > > > It is generally wiser to split the webservers from the appservers; > > that will save on memory footprints from each respectively. That alone > > can give each machine a specific task to accomplish... generally more > > efficiently. But I would assume you know this. > > And it is wise to split database from middleware, and not try to saddle > PostgreSQL with requirements to support Java in-process. _IF_ java stored > procedures are implemented, it should be via something like a) oracle's > extproc (start a separate process to load the function) b) some of perl > java tools (they start a jdk in a separate process and communicate with it > using RMI). > > > Problem with java-pgsql integration is the threads model: Java really > really wants threads. Postgres doesn't do threads. So if most simple way > is attempted, you will incur overhead of starting up JVM for each backend > (a few seconds as opposed to milliseconds) and non-shared 30M of memory > per backend (as opposed to currently <3 megs of non-shared memory per > backend). > > > Using something like WebLogic, WebSphere, or Orion would be a wiser > > approach. For the company with the low budget, Orion is only something > > like $2000, and it has full J2EE support, including EJBs, etc. Try > > finding that kind of richness in Tomcat. Also, Orion takes up only > > 40-50mb at start, which is really fairly reasonable; ram is cheap > > anyways... a server that has to perform complicated algorithms to a > > large audience but has hardly any ram shouldn't be on the internet > > anyways; unless it can handle it. > > _ONLY_ 40-50Mb?! Egads, I'm hard pressed to find any other piece of > (non-windows, non-java) software that takes 40-50M just to start up! > > I worked with both CrapLogic and CrapSphere. Weblogic takes 20-60 seconds > to start up on P3-800, that, IMHO, is ridiculous. > > It is not only issue of memory, its easy to throw memory at the problem, > its an issue of _incremental use_ of memory. As you scale > > > I feel that you don't really have enough experience with _java_ to > > judge it accurately. Frankly, the JVM is quite small nowadays, > > considering the amount of base classes that sit in memory much of the > > time. And the JVMs are really much faster these days. Java is still > > slow for 2 reasons: 1) Developers who don't optimize their code as > > they write it, 2) Bytecode interpretation is and probably never will > > be as fast as something like C/C++. But it certainly isn't the JVM > > itself slowing it down because of some "extended memory" that it lives > > in. Any reasonable server should have absolutely no problems if the > > jvm is implemented _properly_ (which many packages do not do), etc. If > > you're comparing Java to perl, yes, certainly it's a bit more of a > > beast, but perl quite simply can't keep up in speed and feature > > richness (when was the last time you secured your perl code in a > > redistributable fashion?) > _WHY_ the heck do all base classes need to be in memory all the time? Why > are they so huge? Libc is _far far_ smaller, and libstdc++ is tiny > compared to all the java standard library. > > You know what the answer to it is: Because they are ALL written in java, > as opposed to more sane languages like perl which handcode their "standard > libraries" or the most important pieces of them in C. > Perl is far faster than java in about any practical application I did. > Again, the issue is not speed of JVM versus PP (perl virtual machine), if > you did number crunching in perl and java, they would probably be at par. > Its an issue of standard libraries. They are _horribly slow_. Perl's > hashtables are a very nice piece of optimized C code. Java's hashtables > are written in Java. Need I say more? Java's AWT was a dog. Swing is a dog > and a half, because they reimplemented all the things that are commonly > done in C in Java. > > > The only mistake the developers can make is poorly implementing the > > jvm, but most certainly not Java itself. I've been working on > > architecting and building enterprise level sites and applications for > > nearly 8 years now, and I've seen too many people try to implement > > perl cgi websites for enterprise sites and watch them choke and crawl > > to their knees because of poor system resource handling, lack of > > scalability, etc... I most certainly don't consider a single webserver > > with an appserver and tiny database to be enterprise level either (not > > that I'm inferring you said it was). > You cannot compare a perl CGI script and a J2EE server. Its like comparing > a webserver you wrote yourself vs apache! There are application servers > (or more closely, code libraries) for perl that match what J2EE provides. > > -- > Alex Pilosov | http://www.acedsl.com/home.html > CTO - Acecape, Inc. | AceDSL:The best ADSL in the world > 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) > New York, NY 10018 | > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
* Alex Pilosov <alex@pilosoft.com> wrote: | | Its not a perception. Java is still a dog. Back it up or back out please. The most scalable and stable enterprise solutions out there are today running Java. In Java you actually get more time to concentrate on removing the real performance bottlenecks of your application. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
* "Alex Knight" <knight@phunc.com> wrote: | | Even when compiled into bytecode, Java is much slower than C/C++ when Well, compiling into bytecode is what you always do on the Java platform. There are some native compilers as well for the Java _language_, but these do not produce faster code than what you get with the best of breed just in time compilers. | bechmarked... However, Java does what I need it to. But just to clarify, | the "myth" continues on about "slowness." Feel free to live in the dark. Why do you think IBM jumped on the Java wagon ? Because they needed some cute applets on their desktops ? http://www-1.ibm.com/servers/eserver/iseries/news/05jun2000.htm -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
* Thomas Lockhart <lockhart@fourpalms.org> wrote:
|
|
| The other embedded languages we have start small and can grow
| dynamically. But I don't know what is possible in this regard for
| Java...
The Sun JDK has these argument. I think the IBM JDK got similar
arguments.
-mx <size> Maximum heap size
-ms <size> Initial heap size
--
Gunnar Rønning - gunnar@polygnosis.com
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
* "Robert J. Sanford, Jr." <rsanford@nolimitsystems.com> wrote: | | also take a look at jetty which is a beautiful and | tiny web server designed for embedding in java apps | that also runs servlets and jsps. Tomcat is well known performance dog. Resin is one of the most popular servlet engine and JSP implementations. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
* "Alex Knight" <knight@phunc.com> wrote: | | IMHO, scalability is incredibly important, and perl leaves that out often. | Even with Fast-CGI style servers, perl sucks. Perl is great for admin | interfaces, or low to medium traffic sites. We got a contract last december with a customer that were having some performance problems with a perl web application. The customer has access to the best perl programmers money can buy, but they could not fix the performance problem. We came in to make version 2.0 of the system. In one month we had an implementation in Java that outperformed the perl application by a factor of 10. The customer could stop the leasing of three of the Sun E450 servers they were previously using to run the perl application. We've had similar experiences in other projects. Every migration we've done from Perl->Java has resulted in massive savings. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
> | The other embedded languages we have start small and can grow
> | dynamically. But I don't know what is possible in this regard for
> | Java...
> The Sun JDK has these argument. I think the IBM JDK got similar
> arguments.
> -mx <size> Maximum heap size
> -ms <size> Initial heap size
Right. So in an embedded environment, we would need to set these maximum
sizes beforehand, and hitting the upper limit would cause the
application to fail I suppose...
- Thomas
* Thomas Lockhart <lockhart@fourpalms.org> wrote: | | Right. So in an embedded environment, we would need to set these maximum | sizes beforehand, and hitting the upper limit would cause the | application to fail I suppose... Yup, or rather run out of memory. You could code your application to free more memory when it is running short, e.g. purge caches etc. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
Just curious about one thing. How was the perl app implemented? It seems Solaris doesn't do/fork processes very well which is why Sun pushes threads. Whereas *BSD and Linux do processes about as well as Solaris does threads. Postgresql doesn't do so well on our Solaris 2GB box as it does on a 128MB Linux x86 box. I haven't compared MySQL (threaded) on Solaris vs Linux. Cheerio, Link. At 12:29 PM 9/1/01 +0200, Gunnar Rønning wrote: >* "Alex Knight" <knight@phunc.com> wrote: >| >| IMHO, scalability is incredibly important, and perl leaves that out often. >| Even with Fast-CGI style servers, perl sucks. Perl is great for admin >| interfaces, or low to medium traffic sites. > >We got a contract last december with a customer that were having some >performance problems with a perl web application. The customer has >access to the best perl programmers money can buy, but they could not >fix the performance problem. > >We came in to make version 2.0 of the system. In one month we had an >implementation in Java that outperformed the perl application by a factor >of 10. The customer could stop the leasing of three of the Sun E450 servers >they were previously using to run the perl application. > >We've had similar experiences in other projects. Every migration >we've done from Perl->Java has resulted in massive savings. > >-- >Gunnar Rønning - gunnar@polygnosis.com >Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ > >---------------------------(end of broadcast)--------------------------- >TIP 6: Have you searched our list archives? > >http://www.postgresql.org/search.mpl > >
> | Its not a perception. Java is still a dog. > > Back it up or back out please. > > The most scalable and stable enterprise solutions out there are today > running Java. In Java you actually get more time to concentrate on > removing the real performance bottlenecks of your application. Hehe OK, imagine if the whole of PostgreSQL was written in Java. Yeah, we'd be able to really remove its performance bottlenecks then. Really, I think we're all convinced on that one ;-) Having said that if people want PL/Java then let them write it. Its just another option and that can't hurt... - Andrew
Daniel, thank you kindly for your input. However, mod_perl is absolutely slower than most any j2ee application. If all you are doing is keeping a session variable to count number of hits on a web page, then sure, perl is more than sufficient, possibly faster. But when you start doing anything of importance, enterprise level stuff, you need something scalable in ways java can go, but perl just doesn't seem to have _easy_ or sometimes _existant_ ways to implement. How would you go about synchronizing session data on 10 application servers running mod_perl _without_ using the database to "mirror" that data in memory? It's not very difficult to do it in Java. (Ofcourse, any smart architect would use content switches generally to keep a remote user associated with the initial app server to reduce the necessity of such "replication" technologies). Not sure how you are associating me with windows, but no, all my server stuff is always *nix. My answer on awt and swing was in reference to someone else who was basing their opinion of java on awt/swing's capabilities. Regardless, "applets" using awt/swing can be easily run under Linux Mozilla or Netscape, or HotJava, etc. So you can't really say that's enough to assume we're talking about windows. -Knight -----Original Message----- From: Daniel Kalchev [mailto:daniel@digsys.bg] Sent: Friday, August 31, 2001 11:25 PM To: Alex Knight Cc: Alex Pilosov; pgsql-general@postgresql.org Subject: Re: [WAY OT] Re: [GENERAL] PL/java? Well, mod_perl is not exactly slow... and I believe any JAVA program will be slower than the respective PERL program (there are newbie books for both languages :) But, perhaps you talk WINDOWS? If so, any software on WINDOWS can be slower than any other software on WINDOWS... just because they happen to link so some weird DLL. Daniel >>>"Alex Knight" said: > Not really. > > Yes, AWT sucks. Yes, Swing sucks. Java's gui code can be INCREDIBLY lame. > But for server-side situations, Java can be incredibly scalable. > > I wasn't comparing a perl CGI script and a J2EE server, other than saying > perl simply doesn't offer what J2EE does. Furthermore, I've seen more > newbies > write perl cgi scripts in an enterprise environment and break the site > the minute traffic picks up. > > IMHO, scalability is incredibly important, and perl leaves that out often. > Even with Fast-CGI style servers, perl sucks. Perl is great for admin > interfaces, or low to medium traffic sites. > > -----Original Message----- > From: Alex Pilosov [mailto:alex@pilosoft.com] > Sent: Friday, August 31, 2001 7:35 PM > To: Alex Knight > Cc: pgsql-general@postgresql.org > Subject: [WAY OT] Re: [GENERAL] PL/java? > > > On Fri, 31 Aug 2001, Alex Knight wrote: > > > It is generally wiser to split the webservers from the appservers; > > that will save on memory footprints from each respectively. That alone > > can give each machine a specific task to accomplish... generally more > > efficiently. But I would assume you know this. > > And it is wise to split database from middleware, and not try to saddle > PostgreSQL with requirements to support Java in-process. _IF_ java stored > procedures are implemented, it should be via something like a) oracle's > extproc (start a separate process to load the function) b) some of perl > java tools (they start a jdk in a separate process and communicate with it > using RMI). > > > Problem with java-pgsql integration is the threads model: Java really > really wants threads. Postgres doesn't do threads. So if most simple way > is attempted, you will incur overhead of starting up JVM for each backend > (a few seconds as opposed to milliseconds) and non-shared 30M of memory > per backend (as opposed to currently <3 megs of non-shared memory per > backend). > > > Using something like WebLogic, WebSphere, or Orion would be a wiser > > approach. For the company with the low budget, Orion is only something > > like $2000, and it has full J2EE support, including EJBs, etc. Try > > finding that kind of richness in Tomcat. Also, Orion takes up only > > 40-50mb at start, which is really fairly reasonable; ram is cheap > > anyways... a server that has to perform complicated algorithms to a > > large audience but has hardly any ram shouldn't be on the internet > > anyways; unless it can handle it. > > _ONLY_ 40-50Mb?! Egads, I'm hard pressed to find any other piece of > (non-windows, non-java) software that takes 40-50M just to start up! > > I worked with both CrapLogic and CrapSphere. Weblogic takes 20-60 seconds > to start up on P3-800, that, IMHO, is ridiculous. > > It is not only issue of memory, its easy to throw memory at the problem, > its an issue of _incremental use_ of memory. As you scale > > > I feel that you don't really have enough experience with _java_ to > > judge it accurately. Frankly, the JVM is quite small nowadays, > > considering the amount of base classes that sit in memory much of the > > time. And the JVMs are really much faster these days. Java is still > > slow for 2 reasons: 1) Developers who don't optimize their code as > > they write it, 2) Bytecode interpretation is and probably never will > > be as fast as something like C/C++. But it certainly isn't the JVM > > itself slowing it down because of some "extended memory" that it lives > > in. Any reasonable server should have absolutely no problems if the > > jvm is implemented _properly_ (which many packages do not do), etc. If > > you're comparing Java to perl, yes, certainly it's a bit more of a > > beast, but perl quite simply can't keep up in speed and feature > > richness (when was the last time you secured your perl code in a > > redistributable fashion?) > _WHY_ the heck do all base classes need to be in memory all the time? Why > are they so huge? Libc is _far far_ smaller, and libstdc++ is tiny > compared to all the java standard library. > > You know what the answer to it is: Because they are ALL written in java, > as opposed to more sane languages like perl which handcode their "standard > libraries" or the most important pieces of them in C. > Perl is far faster than java in about any practical application I did. > Again, the issue is not speed of JVM versus PP (perl virtual machine), if > you did number crunching in perl and java, they would probably be at par. > Its an issue of standard libraries. They are _horribly slow_. Perl's > hashtables are a very nice piece of optimized C code. Java's hashtables > are written in Java. Need I say more? Java's AWT was a dog. Swing is a dog > and a half, because they reimplemented all the things that are commonly > done in C in Java. > > > The only mistake the developers can make is poorly implementing the > > jvm, but most certainly not Java itself. I've been working on > > architecting and building enterprise level sites and applications for > > nearly 8 years now, and I've seen too many people try to implement > > perl cgi websites for enterprise sites and watch them choke and crawl > > to their knees because of poor system resource handling, lack of > > scalability, etc... I most certainly don't consider a single webserver > > with an appserver and tiny database to be enterprise level either (not > > that I'm inferring you said it was). > You cannot compare a perl CGI script and a J2EE server. Its like comparing > a webserver you wrote yourself vs apache! There are application servers > (or more closely, code libraries) for perl that match what J2EE provides. > > -- > Alex Pilosov | http://www.acedsl.com/home.html > CTO - Acecape, Inc. | AceDSL:The best ADSL in the world > 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) > New York, NY 10018 | > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
The problem with this discussion on Java versus Pick_Your_Favorite_Skript ing_Language is that many of the people participating don't have experience with Java, or even understand Java's place in the programming world. I don't look at this discussion as a flame war, but as a good thread about the practicality of adding Java support to PostgreSQL. Java's strengths have proven to be for server-side J2EE based applications (not _really_ for pure java server applications like a database server). Yes, there are java apps/servers that have slipped through and are very powerful but for the most part, tend to suck(NetBeans for example, is fairly impressive if you look closely at some of the capabilities is has... like the speed of the window refresh is NEARLY that of a native app). Something like PostgreSQL will ALWAYS be faster built under something like C and platform specific assembly. So really, you can't base the entire basis of a programming language based on the purpose of an entirely different language. For example, have you ever developed "cgi" applications using C? A long long time ago, _I_ did. It was a mess, and it still is a mess. Wouldn't that say something about C's likeliness to not be meant for cgi? Let's compare apples and apples from now on... I would also be very interested to see some "negative" comments from people who _have_ had enough experience developing j2ee and general java, versus "negative" comments from people who've heard about java. No offense, let's just not cloud the discussion with imaginary facts. -Knight -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Andrew Snow Sent: Monday, September 03, 2001 6:42 AM To: 'Gunnar Rønning' Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? > | Its not a perception. Java is still a dog. > > Back it up or back out please. > > The most scalable and stable enterprise solutions out there are today > running Java. In Java you actually get more time to concentrate on > removing the real performance bottlenecks of your application. Hehe OK, imagine if the whole of PostgreSQL was written in Java. Yeah, we'd be able to really remove its performance bottlenecks then. Really, I think we're all convinced on that one ;-) Having said that if people want PL/Java then let them write it. Its just another option and that can't hurt... - Andrew ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
>>>>> "Alex" == Alex Knight <knight@phunc.com> writes: Alex> However, mod_perl is absolutely slower than most any j2ee application. Alex> If all you are doing is keeping a session variable to count number of hits Alex> on a web page, then sure, perl is more than sufficient, possibly faster. Alex> But when you start doing anything of importance, enterprise level stuff, Alex> you need something scalable in ways java can go, but perl just doesn't Alex> seem to have _easy_ or sometimes _existant_ ways to implement. I can't let this stand. This is not a universal opinion or observation. Obviously, *I* have an agenda to promote as well, but what I'm quoting here is not the only truth availablel, so test it out yourself, or get an independant opinion. Alex> How would you go about synchronizing session data on 10 Alex> application servers running mod_perl _without_ using the Alex> database to "mirror" that data in memory? It's not very Alex> difficult to do it in Java. Whatever you can do in Java here, you can do in mod_perl. Perl is close enough to the metal to get at anything Java can reach, and I'd argue even closer, since it's trivial to link C (or even Java) with Perl. :) Can we stop bickering now? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
No offense, but I've been developing under your language since nearly it's public conception... and perl is _great_. Frankly, I don't want to argue with you, because you'll simply defend your own creation without reasonably evaluating the situation. But I think everyone needs to remember that we shouldn't make a decision about this because of everyone's political stances behind languages, especially if they haven't had development experience with it. -Knight -----Original Message----- From: Randal L. Schwartz [mailto:merlyn@stonehenge.com] Sent: Monday, September 03, 2001 1:37 PM To: Alex Knight Cc: Daniel Kalchev; Alex Pilosov; pgsql-general@postgresql.org Subject: Re: [WAY OT] Re: [GENERAL] PL/java? >>>>> "Alex" == Alex Knight <knight@phunc.com> writes: Alex> However, mod_perl is absolutely slower than most any j2ee application. Alex> If all you are doing is keeping a session variable to count number of hits Alex> on a web page, then sure, perl is more than sufficient, possibly faster. Alex> But when you start doing anything of importance, enterprise level stuff, Alex> you need something scalable in ways java can go, but perl just doesn't Alex> seem to have _easy_ or sometimes _existant_ ways to implement. I can't let this stand. This is not a universal opinion or observation. Obviously, *I* have an agenda to promote as well, but what I'm quoting here is not the only truth availablel, so test it out yourself, or get an independant opinion. Alex> How would you go about synchronizing session data on 10 Alex> application servers running mod_perl _without_ using the Alex> database to "mirror" that data in memory? It's not very Alex> difficult to do it in Java. Whatever you can do in Java here, you can do in mod_perl. Perl is close enough to the metal to get at anything Java can reach, and I'd argue even closer, since it's trivial to link C (or even Java) with Perl. :) Can we stop bickering now? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
> No offense, but I've been developing under your language > since nearly it's public conception... and perl is _great_. > > Frankly, I don't want to argue with you, because you'll > simply defend your own creation without reasonably > evaluating the situation. > > But I think everyone needs to remember that we shouldn't > make a decision about this because of everyone's political > stances behind languages, especially if they haven't had > development experience with it. i think that you missed the point that mr. schwartz is trying to make - anything you can do in java, you _can_ do in perl. in my opinion, he isn't trying to say that you _should_ do it in perl. he might do it in perl but, after all, there is more than one way to get things done :) one of the things that i find refreshing about perl is its lack of corporate attitude. perl doesn't have any aspirations to be anything other than what it is. it isn't being driven by corporate marketing forcing it to beat someone else. the only thing that is driving it is the needs and desires of its developers to evolve it to meet the needs of its users. and i do almost all of my server-side development in java! > Alex> How would you go about synchronizing session data on 10 > Alex> application servers running mod_perl _without_ using the > Alex> database to "mirror" that data in memory? It's not very > Alex> difficult to do it in Java. are you saying that it isn't very difficult for you to go out and write this yourself in java or are you saying that it isn't difficult for you to use what someone else has already written? if the former and if you want to do something like this in perl you can start with reading the section in the camel book on tcp clients and servers. if you feel that tcp has too high of an overhead then you can read the section on udp clients and servers. if the latter, look on cpan and if what you want isn't there then you can step and contribute. ohmigod, i'm defending perl and guess what? i _still_ do almost all of my server-side development in java! > Alex> However, mod_perl is absolutely slower than most any > Alex> > j2ee application. If all you are doing is keeping > Alex> a session variable to count number of hits on a web > Alex> page, then sure, perl is more than sufficient, > Alex> possibly faster. But when you start doing anything > Alex> of importance, enterprise level stuff, you need > Alex> something scalable in ways java can go, but perl > Alex> just doesn't seem to have _easy_ or sometimes > Alex> _existant_ ways to implement. i don't like language bigots. i just don't. most languages are quite capable and anyone that denies the viability of one language is generally uninformed. just because perl doesn't get the four-color glossy press that java gets doesn't mean that it isn't capable it just means it doesn't get the four-color glossy press. just because you don't see something arrive in your box every day trumpeting perl doesn't mean it can't do what you want and do it well. it just means that there isn't anyone out there blowing the horn in your ear. we have already seen on this topic someone spouting off that java was way too slow, that c++ was sooo much better, that having a jvm included in the distribution would make postgres hog memory and crash unexpectedly. all of this without any links to nice evidence. all of this while degrading java based on the performance of one application (tomcat) that pretty much everyone agrees is a dog. personally, i see a _lot_ of similarities between his issues with java and your issues with perl. 7-11 burritos. rjsjr
OK. If I find some time, I'm going to attempt to do some things
that java does well, that I think perl can not do easily.
-Knight
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of Robert J.
Sanford, Jr.
Sent: Monday, September 03, 2001 6:02 PM
To: pgsql-general@postgresql.org
Cc: Randal L. Schwartz
Subject: Re: [WAY OT] Re: [GENERAL] PL/java?
> No offense, but I've been developing under your language
> since nearly it's public conception... and perl is _great_.
>
> Frankly, I don't want to argue with you, because you'll
> simply defend your own creation without reasonably
> evaluating the situation.
>
> But I think everyone needs to remember that we shouldn't
> make a decision about this because of everyone's political
> stances behind languages, especially if they haven't had
> development experience with it.
i think that you missed the point that mr. schwartz is trying to
make - anything you can do in java, you _can_ do in perl. in my
opinion, he isn't trying to say that you _should_ do it in perl.
he might do it in perl but, after all, there is more than one
way to get things done :)
one of the things that i find refreshing about perl is its lack
of corporate attitude. perl doesn't have any aspirations to be
anything other than what it is. it isn't being driven by
corporate marketing forcing it to beat someone else. the only
thing that is driving it is the needs and desires of its
developers to evolve it to meet the needs of its users.
and i do almost all of my server-side development in java!
> Alex> How would you go about synchronizing session data on 10
> Alex> application servers running mod_perl _without_ using the
> Alex> database to "mirror" that data in memory? It's not very
> Alex> difficult to do it in Java.
are you saying that it isn't very difficult for you to go out
and write this yourself in java or are you saying that it isn't
difficult for you to use what someone else has already written?
if the former and if you want to do something like this in perl
you can start with reading the section in the camel book on tcp
clients and servers. if you feel that tcp has too high of an
overhead then you can read the section on udp clients and servers.
if the latter, look on cpan and if what you want isn't there then
you can step and contribute.
ohmigod, i'm defending perl and guess what? i _still_ do almost
all of my server-side development in java!
> Alex> However, mod_perl is absolutely slower than most any
> Alex> > j2ee application. If all you are doing is keeping
> Alex> a session variable to count number of hits on a web
> Alex> page, then sure, perl is more than sufficient,
> Alex> possibly faster. But when you start doing anything
> Alex> of importance, enterprise level stuff, you need
> Alex> something scalable in ways java can go, but perl
> Alex> just doesn't seem to have _easy_ or sometimes
> Alex> _existant_ ways to implement.
i don't like language bigots. i just don't. most languages are
quite capable and anyone that denies the viability of one
language is generally uninformed. just because perl doesn't get
the four-color glossy press that java gets doesn't mean that it
isn't capable it just means it doesn't get the four-color glossy
press. just because you don't see something arrive in your box
every day trumpeting perl doesn't mean it can't do what you want
and do it well. it just means that there isn't anyone out there
blowing the horn in your ear.
we have already seen on this topic someone spouting off that
java was way too slow, that c++ was sooo much better, that
having a jvm included in the distribution would make postgres
hog memory and crash unexpectedly. all of this without any
links to nice evidence. all of this while degrading java based
on the performance of one application (tomcat) that pretty much
everyone agrees is a dog.
personally, i see a _lot_ of similarities between his issues with
java and your issues with perl. 7-11 burritos.
rjsjr
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Hi Alex, Saying that mod_perl is slower than any java apps is purely marketing for java. An other guy told me that one day, I just bench it to show him how java developper just talk marketing. So the result was that with small users the performance was the same and with many user mod_perl is really speediest. Secondly mod_perl doesn't crash the system, under Linux using Java is a waste of time and a leak of memory ! Marketing is probably why daniel talk about Win$ When first Java was out it was called the "Perl killer", so after many years Perl is most uses than Java, ask you why ??? For your other words what you do in Java can be done in perl more quickly more efficiently and with writing many less lines ! An other example is the Oracle XML/SQL Servlet that it was plan to use in my company. After hearing too many marketing words I write the same in perl in 3 days and extend the possibility with no limits. Now they're using Perl, ask you why ? This is use in the entreprise commercial application that I think you call entreprise level ! At this time Perl is the only really portable language over any OS. In my opinion PL/Java is purely a waste of time but some have time so why not ! Sorry but I can not let you say words like that, we are not newbe :-( In your way I can tell you that before using Perl I also preach for Java :-) But after rewritten many time the same apps with the differents versions of Java and the OS where it should work it ended to decide me: no more Java ! Regards Gilles Darold Alex Knight wrote: > Daniel, thank you kindly for your input. > > However, mod_perl is absolutely slower than most any j2ee application. > If all you are doing is keeping a session variable to count number of hits > on a web page, then sure, perl is more than sufficient, possibly faster. > But when you start doing anything of importance, enterprise level stuff, > you need something scalable in ways java can go, but perl just doesn't > seem to have _easy_ or sometimes _existant_ ways to implement. > > How would you go about synchronizing session data on 10 application servers > running mod_perl _without_ using the database to "mirror" that data in > memory? It's not very difficult to do it in Java. (Ofcourse, any smart > architect would use content switches generally to keep a remote user > associated with the initial app server to reduce the necessity of such > "replication" technologies). > > Not sure how you are associating me with windows, but no, all my server > stuff is always *nix. My answer on awt and swing was in reference to > someone else who was basing their opinion of java on awt/swing's > capabilities. Regardless, "applets" using awt/swing can be easily run > under Linux Mozilla or Netscape, or HotJava, etc. So you can't really > say that's enough to assume we're talking about windows. > > -Knight
After having seen this Perl / Java debate go back and forth... I can't help myself... <RANT> The answer is Python !!! For the best middleware you're ever likely to integrate with Postgresql : http://www.zope.org To see its "enterprise scalability": http://www.zope.org/About To see it taking LOTS of hits: http://ns1.zope.org:82/ To see it NOT using much memory at all: http://ns1.zope.org:82/cgi-bin/zope-track.pl (this one loads kinda slow, maybe cause it's done in Perl?) </RANT> The real point here is that programmers are religious about their choice of language, and highly resistant to changing, which is why Postgres supports so many languages! I happen to prefer python, but that's just me. http://www.python.org if you're curious Adam At 06:21 AM 9/4/01, you wrote: >Hi Alex, > >Saying that mod_perl is slower than any java apps is purely marketing >for java. An other guy told me that one day, I just bench it to show him >how java developper just talk marketing. So the result was that with small >users the performance was the same and with many user mod_perl is >really speediest. Secondly mod_perl doesn't crash the system, under Linux >using Java is a waste of time and a leak of memory ! Marketing is probably >why daniel talk about Win$ > >When first Java was out it was called the "Perl killer", so after many years >Perl is most uses than Java, ask you why ??? > >For your other words what you do in Java can be done in perl more quickly >more efficiently and with writing many less lines ! > >An other example is the Oracle XML/SQL Servlet that it was plan to use >in my company. After hearing too many marketing words I write the same >in perl in 3 days and extend the possibility with no limits. Now they're using >Perl, ask you why ? This is use in the entreprise commercial application that >I think you call entreprise level ! > >At this time Perl is the only really portable language over any OS. > >In my opinion PL/Java is purely a waste of time but some have time so why >not ! > >Sorry but I can not let you say words like that, we are not newbe :-( > >In your way I can tell you that before using Perl I also preach for Java :-) >But >after rewritten many time the same apps with the differents versions of Java >and the OS where it should work it ended to decide me: no more Java ! > >Regards > >Gilles Darold > >Alex Knight wrote: > > > Daniel, thank you kindly for your input. > > > > However, mod_perl is absolutely slower than most any j2ee application. > > If all you are doing is keeping a session variable to count number of hits > > on a web page, then sure, perl is more than sufficient, possibly faster. > > But when you start doing anything of importance, enterprise level stuff, > > you need something scalable in ways java can go, but perl just doesn't > > seem to have _easy_ or sometimes _existant_ ways to implement. > > > > How would you go about synchronizing session data on 10 application servers > > running mod_perl _without_ using the database to "mirror" that data in > > memory? It's not very difficult to do it in Java. (Ofcourse, any smart > > architect would use content switches generally to keep a remote user > > associated with the initial app server to reduce the necessity of such > > "replication" technologies). > > > > Not sure how you are associating me with windows, but no, all my server > > stuff is always *nix. My answer on awt and swing was in reference to > > someone else who was basing their opinion of java on awt/swing's > > capabilities. Regardless, "applets" using awt/swing can be easily run > > under Linux Mozilla or Netscape, or HotJava, etc. So you can't really > > say that's enough to assume we're talking about windows. > > > > -Knight > > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster
This is a valid concern for Solaris and I wish we had an answer. I am going to contact some Sun people to see if I can figure out a workaround. > Just curious about one thing. > > How was the perl app implemented? > > It seems Solaris doesn't do/fork processes very well which is why Sun > pushes threads. > > Whereas *BSD and Linux do processes about as well as Solaris does threads. > > Postgresql doesn't do so well on our Solaris 2GB box as it does on a 128MB > Linux x86 box. > > I haven't compared MySQL (threaded) on Solaris vs Linux. > > Cheerio, > Link. > > At 12:29 PM 9/1/01 +0200, Gunnar R?nning wrote: > >* "Alex Knight" <knight@phunc.com> wrote: > >| > >| IMHO, scalability is incredibly important, and perl leaves that out often. > >| Even with Fast-CGI style servers, perl sucks. Perl is great for admin > >| interfaces, or low to medium traffic sites. > > > >We got a contract last december with a customer that were having some > >performance problems with a perl web application. The customer has > >access to the best perl programmers money can buy, but they could not > >fix the performance problem. > > > >We came in to make version 2.0 of the system. In one month we had an > >implementation in Java that outperformed the perl application by a factor > >of 10. The customer could stop the leasing of three of the Sun E450 servers > >they were previously using to run the perl application. > > > >We've had similar experiences in other projects. Every migration > >we've done from Perl->Java has resulted in massive savings. > > > >-- > >Gunnar R?nning - gunnar@polygnosis.com > >Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ > > > >---------------------------(end of broadcast)--------------------------- > >TIP 6: Have you searched our list archives? > > > >http://www.postgresql.org/search.mpl > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
fellow list members: please accept my apologies for the following post that i am responsible for. the post below ended with a personal attack towards the person i was responding to rather than keeping with what i felt were the well-reasoned arguments that i started with. such attacks have no place on this list and i apologize for my behaviour to both the original author and to the other members of the community. sincerely, rjsjr > -----Original Message----- > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Robert J. > Sanford, Jr. > Sent: Friday, August 31, 2001 11:02 PM > To: pgsql-general@postgresql.org > Subject: Re: [GENERAL] PL/java? > > > note - i don't work for any of the companies whose products > are mentioned below. i have performed evaluations of these > products and the support provided when attempting to determine > what platform my company's systems should run on. unfortunately, > i did not choose orion and i am suffering for it now... > > some goober blathered thusly: > > Have you ever actually used Java on an enterprise-level > > application? Ever see the Tomcat webserver? It uses > > 100MB of memory, drives the load on our server up to 8, > > and doesn't serve nearly as fast apache. Do you really > > want that in your database? > > first - don't complain about java because you or someone > in your group/department/company made a poor decision on > what tools to use. that's like complaining about mexican > food when the only experience you have is eating an out- > dated frozen burrito from the 7-11 freezer. > > when looking at the performance of java you have to take > a look at two things - first you have to compare various > java implementations against each other and then you have > to compare the best java implementations against native > c/c++ code. the following link does that. the java tests > include tomcat, orion, websphere, and resin. jrun and > weblogic were originally included in the testing but > were both removed at their companies' request. > > the tests also compare orion vs microsoft asp running on > win2k and iis5. all tests run on the same hardware. > > what i believe these tests clearly demonstrate is that > java is not the problem, the implementation applications > based on java is. i also do not believe that tomcat is > a fair representation of java performance in that it is > intended to be a reference implementation. as such, the > code base should sacrifice performance for clarity. > > http://www.orionserver.com/benchmarks/benchmark.html > > > while not in the benchmark i would also like to > recommend jetty as an app server. it is an opensource, > 100% java web and application server. in its base form > it is "just" a web, servlet, and jsp engine. it does, > however, have contributed code providing integration > with other j2ee opensource projects such as the JBoss > EJB engine. > > you can find the jetty home page at: > http://jetty.mortbay.com/ > > and then they blathered some more: > > Compare the speed of Oracle 8 with 8i if you don't > > believe me. The stability is also much worse. Ever > > see a JVM on any platform that didn't crash if you > > looked at it cockeyed? Ever really trust the garbage > > collection? I don't. I've found a memory leak in IBM > > developed java libraries. Gotta restart that app > > every once in a while to reclaim system resources it > > gobbled up and never gave back. > > some mention was made regarding the performance of > the oracle8i application server. well, oracle has > realized that their performance was sub-optimal and > rectified the situation by licensing the orion server > for oracle9i. while money and politics most certainly > play a part in any licensing arrangement they must > also realize that making customers happy through the > performance of their applications will lead to more > money. the link to the press release is below. > > http://www.oracle.com/corporate/press/index.html?759347.html > > all of that being said... > > i don't think that the person that started this thread > did anything wrong by making the request they did. that > is what opensource is all about - contributions, even > just contributions of ideas, are welcomed. even so, there > are several options that i see for getting it implemented: > 1) its an open source project so implement it yourself. > while i have never worked on modifying the code base > i am extremely confident that the current developers > will be more than willing to give you advice and > pointers. > 2) if #1 is not feasible either because you don't have > the time, the inclination, or the experience then > you can write a contract that will pay one of the > postgres developers to implement it for you. > 3) if that isn't feasible you can try to get a volunteer > to do so. > 4) if that isn't feasible then you either have to live > with what you have, go elsewhere, or be quiet. > > to the person that blathered thusly in response to the > request for java: > > Merits of the language notwithstanding, I'd rather > > not have a buggy, still under development > > (depreciating everything under the sun with every > > new iteration) JVM parasite in my DB. > > informed and intelligent debate is good. given that i > believe such to be true, i would request that you > refrain from blathering such vitriol and uninformed > nonsense. not only is it for the good of the people > on the list who don't want to hear it but it will > also do you good by not telling everyone out there > that you are a very silly person that doesn't deal > with logic and/or facts. > > to everyone else on the list - if we all contribute > a penny we could probably buy enough burritos from > 7-11 to make sure that his hands and mouth are busy > for a good long while. > > rjsjr > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
Hi, I have been following this noisy thread from a distance. I have had mixed experiences with perl and databases. Most have been bad. A few have been good. I have seen perl choke an NT server to death with very few requests for example (the database was SQL server). I also run a perl database for one of my clients using dbman. It works very well for their needs. I would not say either way that perl or Java are bad news. But I will say that discovering JSP has turned me away from perl because I can make them work without handcoding. I am now putting a lot of my logic in SQL code stored in Postgresql and calling the functions from JSP. If I really need some heavy duty stuff I would probably put it in beans that i would have programmed by an expert. We have the chance to have many languages to choose from. Use the one that works best (or works best for you). Share the tips and techniques. And please stop shouting at each other, the real enemy is not within the Postgresql camp... <end of calming down rant> Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Macromedia UltraDev with PostgreSQL http://www.animaproductions.com/ultra.html
Hi Gilles, You did not read what I wrote very well. First, I said that mod_perl was slower than "most any j2ee application". If you knew what j2ee was, you'd know that it's generally limited to server-side internet apps like servlets, jsps, etc... Not to mention, I do try to give perl credit where due. If java crashes your server, that's because either the vendor that has the jvm incorporated sucks, or your program was written poorly. I have _never_ crashed a system or eaten up memory when everything is properly installed. Java is NOT a cure all language. I honestly feel that because of the way the interpreter is packaged, it can not be used for every single situation, like C could for example. But I feel java would be incredibly appropriate in postgresql. I see it this way. All the people who really know Java's capabilities, and know that it can be used without problem, will want Java in the db. All the others who think "java is _always_ slow" or "java leaks memory" or "java is a waste of time" won't be using the java extensions ANYWAYS. As for perl, I probably came off a little wrong. In a reply to Randal, I did state that I liked perl very much, and I've been developing with it forever. Perl _is_ amazing, and there is no limit to what you can do with it. However, in some cases, Java does things better (just like perl does things faster than Java in certain situations). But perl has had the "most uses" for so many years because it is easy to learn, not truely object oriented (atleast the past few years have been that way), does not require compiling to simplify the execution process (i.e. fully interpreted), etc. Expand on your "enterprise application". A true enterprise application takes more than 3 days time to design and implement. Most "real" enterprise applications have multiple layers of logic, etc. I don't consider a script that queries a database for a password by 100,000 people a day to really be considered as Enterprise either. If I was new to programming, and I started "preaching Java" right off the bat, this conversation wouldn't be warranted. In fact, I run into these types of Java developers who go around saying they think Java is the best language ever, etc etc but don't really have the experience to make that claim. Anyways, I really didn't want this to get into "my language is better than yours", and let's drop that immediately. My entire purpose here was to help defend the idea of implementing Java as a PL in PGSQL. Anyone else have any comments about the java implementation? -Knight -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Gilles DAROLD Sent: Tuesday, September 04, 2001 3:22 AM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? Hi Alex, Saying that mod_perl is slower than any java apps is purely marketing for java. An other guy told me that one day, I just bench it to show him how java developper just talk marketing. So the result was that with small users the performance was the same and with many user mod_perl is really speediest. Secondly mod_perl doesn't crash the system, under Linux using Java is a waste of time and a leak of memory ! Marketing is probably why daniel talk about Win$ When first Java was out it was called the "Perl killer", so after many years Perl is most uses than Java, ask you why ??? For your other words what you do in Java can be done in perl more quickly more efficiently and with writing many less lines ! An other example is the Oracle XML/SQL Servlet that it was plan to use in my company. After hearing too many marketing words I write the same in perl in 3 days and extend the possibility with no limits. Now they're using Perl, ask you why ? This is use in the entreprise commercial application that I think you call entreprise level ! At this time Perl is the only really portable language over any OS. In my opinion PL/Java is purely a waste of time but some have time so why not ! Sorry but I can not let you say words like that, we are not newbe :-( In your way I can tell you that before using Perl I also preach for Java :-) But after rewritten many time the same apps with the differents versions of Java and the OS where it should work it ended to decide me: no more Java ! Regards Gilles Darold Alex Knight wrote: > Daniel, thank you kindly for your input. > > However, mod_perl is absolutely slower than most any j2ee application. > If all you are doing is keeping a session variable to count number of hits > on a web page, then sure, perl is more than sufficient, possibly faster. > But when you start doing anything of importance, enterprise level stuff, > you need something scalable in ways java can go, but perl just doesn't > seem to have _easy_ or sometimes _existant_ ways to implement. > > How would you go about synchronizing session data on 10 application servers > running mod_perl _without_ using the database to "mirror" that data in > memory? It's not very difficult to do it in Java. (Ofcourse, any smart > architect would use content switches generally to keep a remote user > associated with the initial app server to reduce the necessity of such > "replication" technologies). > > Not sure how you are associating me with windows, but no, all my server > stuff is always *nix. My answer on awt and swing was in reference to > someone else who was basing their opinion of java on awt/swing's > capabilities. Regardless, "applets" using awt/swing can be easily run > under Linux Mozilla or Netscape, or HotJava, etc. So you can't really > say that's enough to assume we're talking about windows. > > -Knight ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
Python is a great language too. For scripts, I tend to write more python scripts than perl these days, simply because python better suits my needs and the base class library seems larger than perl's after install, not that adding libs aren't easy. But I can write compact scripts without cryptoblinding the user reading the script... Zope is quite powerful too. But Zope still has a long way to travel until it can make it to the Enterprise arena. I know a lot of the Zope developers, and zope.org specifically gets lots of hits, but it's not getting nearly as many as a Bankofamerica.com would get. -Knight -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Adam Manock Sent: Tuesday, September 04, 2001 4:35 AM To: pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? After having seen this Perl / Java debate go back and forth... I can't help myself... <RANT> The answer is Python !!! For the best middleware you're ever likely to integrate with Postgresql : http://www.zope.org To see its "enterprise scalability": http://www.zope.org/About To see it taking LOTS of hits: http://ns1.zope.org:82/ To see it NOT using much memory at all: http://ns1.zope.org:82/cgi-bin/zope-track.pl (this one loads kinda slow, maybe cause it's done in Perl?) </RANT> The real point here is that programmers are religious about their choice of language, and highly resistant to changing, which is why Postgres supports so many languages! I happen to prefer python, but that's just me. http://www.python.org if you're curious Adam At 06:21 AM 9/4/01, you wrote: >Hi Alex, > >Saying that mod_perl is slower than any java apps is purely marketing >for java. An other guy told me that one day, I just bench it to show him >how java developper just talk marketing. So the result was that with small >users the performance was the same and with many user mod_perl is >really speediest. Secondly mod_perl doesn't crash the system, under Linux >using Java is a waste of time and a leak of memory ! Marketing is probably >why daniel talk about Win$ > >When first Java was out it was called the "Perl killer", so after many years >Perl is most uses than Java, ask you why ??? > >For your other words what you do in Java can be done in perl more quickly >more efficiently and with writing many less lines ! > >An other example is the Oracle XML/SQL Servlet that it was plan to use >in my company. After hearing too many marketing words I write the same >in perl in 3 days and extend the possibility with no limits. Now they're using >Perl, ask you why ? This is use in the entreprise commercial application that >I think you call entreprise level ! > >At this time Perl is the only really portable language over any OS. > >In my opinion PL/Java is purely a waste of time but some have time so why >not ! > >Sorry but I can not let you say words like that, we are not newbe :-( > >In your way I can tell you that before using Perl I also preach for Java :-) >But >after rewritten many time the same apps with the differents versions of Java >and the OS where it should work it ended to decide me: no more Java ! > >Regards > >Gilles Darold > >Alex Knight wrote: > > > Daniel, thank you kindly for your input. > > > > However, mod_perl is absolutely slower than most any j2ee application. > > If all you are doing is keeping a session variable to count number of hits > > on a web page, then sure, perl is more than sufficient, possibly faster. > > But when you start doing anything of importance, enterprise level stuff, > > you need something scalable in ways java can go, but perl just doesn't > > seem to have _easy_ or sometimes _existant_ ways to implement. > > > > How would you go about synchronizing session data on 10 application servers > > running mod_perl _without_ using the database to "mirror" that data in > > memory? It's not very difficult to do it in Java. (Ofcourse, any smart > > architect would use content switches generally to keep a remote user > > associated with the initial app server to reduce the necessity of such > > "replication" technologies). > > > > Not sure how you are associating me with windows, but no, all my server > > stuff is always *nix. My answer on awt and swing was in reference to > > someone else who was basing their opinion of java on awt/swing's > > capabilities. Regardless, "applets" using awt/swing can be easily run > > under Linux Mozilla or Netscape, or HotJava, etc. So you can't really > > say that's enough to assume we're talking about windows. > > > > -Knight > > >---------------------------(end of broadcast)--------------------------- >TIP 4: Don't 'kill -9' the postmaster ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
I'm interested to see the results, Cheers. -----Original Message----- From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] Sent: Tuesday, September 04, 2001 9:16 AM To: Lincoln Yeoh Cc: Gunnar Ronning; Alex Knight; Alex Pilosov; pgsql-general@postgresql.org Subject: Re: [GENERAL] [WAY OT] Re: PL/java? This is a valid concern for Solaris and I wish we had an answer. I am going to contact some Sun people to see if I can figure out a workaround. > Just curious about one thing. > > How was the perl app implemented? > > It seems Solaris doesn't do/fork processes very well which is why Sun > pushes threads. > > Whereas *BSD and Linux do processes about as well as Solaris does threads. > > Postgresql doesn't do so well on our Solaris 2GB box as it does on a 128MB > Linux x86 box. > > I haven't compared MySQL (threaded) on Solaris vs Linux. > > Cheerio, > Link. > > At 12:29 PM 9/1/01 +0200, Gunnar R?nning wrote: > >* "Alex Knight" <knight@phunc.com> wrote: > >| > >| IMHO, scalability is incredibly important, and perl leaves that out often. > >| Even with Fast-CGI style servers, perl sucks. Perl is great for admin > >| interfaces, or low to medium traffic sites. > > > >We got a contract last december with a customer that were having some > >performance problems with a perl web application. The customer has > >access to the best perl programmers money can buy, but they could not > >fix the performance problem. > > > >We came in to make version 2.0 of the system. In one month we had an > >implementation in Java that outperformed the perl application by a factor > >of 10. The customer could stop the leasing of three of the Sun E450 servers > >they were previously using to run the perl application. > > > >We've had similar experiences in other projects. Every migration > >we've done from Perl->Java has resulted in massive savings. > > > >-- > >Gunnar R?nning - gunnar@polygnosis.com > >Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ > > > >---------------------------(end of broadcast)--------------------------- > >TIP 6: Have you searched our list archives? > > > >http://www.postgresql.org/search.mpl > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>>>>> "Alex" == Alex Knight <knight@phunc.com> writes: Alex> You did not read what I wrote very well. First, I said that mod_perl was Alex> slower than "most any j2ee application". If you knew what j2ee was, Alex> you'd know that it's generally limited to server-side internet apps Alex> like servlets, jsps, etc... If you'd just stop saying things that can't be backed up, I wouldn't have to keep responding. Where is your proof that mod_perl is "slower than most any j2ee application"? Alex> However, in some cases, Java does things better (just like Alex> perl does things faster than Java in certain situations). I'm still waiting for "Java does things better" to be demonstrated. Alex> But perl has had the "most uses" for so many years because it is Alex> easy to learn, not truely object oriented Perl is a hybrid OO language, just like Java. Now if you compare both of them to Smalltalk, I see your point. But Java has primitive types that cannot be subclassed or extended, just like Perl. There's really no difference. Perhaps you've not read "Object Oriented Perl" by Damian Conway, to see just how rich Perl's object model is, even compared to Java and others. Alex> (atleast the past few Alex> years have been that way), does not require compiling to Alex> simplify the execution process (i.e. fully interpreted), etc. Perl is no more interpreted than Java. Perl's compiler translates the entire program down to bytecodes, and the bytecodes are then executed by the Perl Virtual Machine, just like Java. (I won't bring up any benchmarks here... it's unfair to Java. :) See... it's the nonsense you keep spouting that makes me want to slap you silly. Get a clue. Perl is a serious, mission-critical language, being actively developed by hundreds of people who depend on it to remain stable, fast, and useful. I've seen both. Java has its place. Perl has its place. Stop dissing Perl, because you are apparently unaware of what is actually going on. I guess that would make you a language bigot. Alex> Expand on your "enterprise application". A true enterprise application Alex> takes more than 3 days time to design and implement. Most "real" Alex> enterprise applications have multiple layers of logic, etc. I don't Alex> consider a script that queries a database for a password by 100,000 Alex> people a day to really be considered as Enterprise either. And many "enterprise applications" are completely in Perl. cbs.sportsline.com is 90% Perl. Etoys.com was 100% Perl. imdb.com is 100% perl. valueclick.com is 100% Perl. Amazon.com does all their backend processing in Perl. Boeing uses Perl in every step of their cad/cam process... every number defining the 777 airplane was passed through Perl. Alex> If I was new to programming, and I started "preaching Java" Alex> right off the bat, this conversation wouldn't be warranted. In Alex> fact, I run into these types of Java developers who go around Alex> saying they think Java is the best language ever, etc etc but Alex> don't really have the experience to make that claim. You smell a bit like that now though, mostly through your ignorance of Perl. Maybe you're not "unfounded pro Java", but you are "unfounded anti Perl". And I won't allow that here. I'll certainly permit Perl to lose on its technical merits, but I won't let Perl lose through your ignorance of what it actually can be or do. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
I hate arguing with you. And like I stated in previous posts, I'm not trying to be entirely slanderous to perl... I'm absolutely not anti-perl, so I will apologize for that now. I still use perl on a daily basis. The only reason I stated that Java can be "better" than perl in some areas is because of experiences in general, and because some guy was gungho about perl being the savior's choice of languages for Enterprise applications *cough*. Just as you do not like to see perl discredited without substantial facts, I dislike seeing Java being discredited because people think it is a pure "marketing hype" or because it's JVM on their Windows 98 machine running a swing app crashed their system. I actually am interested in some benchmarks of perl versus java if you have some. This "argument" needs to _end_. Is there anyone else who sees adding java as an advantage? If not, this is pointless. All due respect, Knight -----Original Message----- From: Randal L. Schwartz [mailto:merlyn@stonehenge.com] Sent: Tuesday, September 04, 2001 2:28 PM To: Alex Knight Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? >>>>> "Alex" == Alex Knight <knight@phunc.com> writes: Alex> You did not read what I wrote very well. First, I said that mod_perl was Alex> slower than "most any j2ee application". If you knew what j2ee was, Alex> you'd know that it's generally limited to server-side internet apps Alex> like servlets, jsps, etc... If you'd just stop saying things that can't be backed up, I wouldn't have to keep responding. Where is your proof that mod_perl is "slower than most any j2ee application"? Alex> However, in some cases, Java does things better (just like Alex> perl does things faster than Java in certain situations). I'm still waiting for "Java does things better" to be demonstrated. Alex> But perl has had the "most uses" for so many years because it is Alex> easy to learn, not truely object oriented Perl is a hybrid OO language, just like Java. Now if you compare both of them to Smalltalk, I see your point. But Java has primitive types that cannot be subclassed or extended, just like Perl. There's really no difference. Perhaps you've not read "Object Oriented Perl" by Damian Conway, to see just how rich Perl's object model is, even compared to Java and others. Alex> (atleast the past few Alex> years have been that way), does not require compiling to Alex> simplify the execution process (i.e. fully interpreted), etc. Perl is no more interpreted than Java. Perl's compiler translates the entire program down to bytecodes, and the bytecodes are then executed by the Perl Virtual Machine, just like Java. (I won't bring up any benchmarks here... it's unfair to Java. :) See... it's the nonsense you keep spouting that makes me want to slap you silly. Get a clue. Perl is a serious, mission-critical language, being actively developed by hundreds of people who depend on it to remain stable, fast, and useful. I've seen both. Java has its place. Perl has its place. Stop dissing Perl, because you are apparently unaware of what is actually going on. I guess that would make you a language bigot. Alex> Expand on your "enterprise application". A true enterprise application Alex> takes more than 3 days time to design and implement. Most "real" Alex> enterprise applications have multiple layers of logic, etc. I don't Alex> consider a script that queries a database for a password by 100,000 Alex> people a day to really be considered as Enterprise either. And many "enterprise applications" are completely in Perl. cbs.sportsline.com is 90% Perl. Etoys.com was 100% Perl. imdb.com is 100% perl. valueclick.com is 100% Perl. Amazon.com does all their backend processing in Perl. Boeing uses Perl in every step of their cad/cam process... every number defining the 777 airplane was passed through Perl. Alex> If I was new to programming, and I started "preaching Java" Alex> right off the bat, this conversation wouldn't be warranted. In Alex> fact, I run into these types of Java developers who go around Alex> saying they think Java is the best language ever, etc etc but Alex> don't really have the experience to make that claim. You smell a bit like that now though, mostly through your ignorance of Perl. Maybe you're not "unfounded pro Java", but you are "unfounded anti Perl". And I won't allow that here. I'll certainly permit Perl to lose on its technical merits, but I won't let Perl lose through your ignorance of what it actually can be or do. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
* Lincoln Yeoh <lyeoh@pop.jaring.my> wrote: | | Just curious about one thing. | | How was the perl app implemented? | | It seems Solaris doesn't do/fork processes very well which is why Sun | pushes threads. | I never saw the code of the perl application myself. All I know is that it was running on Solaris with mod_perl and a Sybase database. I think the main reasons for improved performance was related to application design, as we took care to cache a lot of common queries with the new design; I don't think the Perl application went out its way to cache things, in Java we got the caching for free as we used a third party object relational tool to talk with the database. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
* merlyn@stonehenge.com (Randal L. Schwartz) wrote: | | If you'd just stop saying things that can't be backed up, I wouldn't | have to keep responding. ;-) | Where is your proof that mod_perl is "slower than most any j2ee | application"? I don't like to generalize either. I've been on two projects where we have replaced Perl applications with Java applications. The first one was a content management system and the second was an online dating application(like match.com). In both cases we ended up with Java applications that performed better than the Perl applications. The reasons ? - Maybe it was because our Java developers were better than our Perl developers. - Maybe we had learned something the second time implementing the application. Better architecture, system design, etc. - Maybe Java was better suited for the actual applications. In the end there is however no proof to claim that Java applications are faster than mod_perl applications. But having Java in the PgSQL backend would be nice for some, regardless of how well Java compares to Perl. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
>>>>> "Gunnar" == Gunnar Rønning <gunnar@polygnosis.com> writes: Gunnar> In the end there is however no proof to claim that Java applications Gunnar> are faster than mod_perl applications. I'll settle for that. Most of the time I've seen benchmarks, it's been more the skillset of the programmers at stake rather than the languages. Gunnar> But having Java in the PgSQL backend would be nice for some, Gunnar> regardless of how well Java compares to Perl. Yes, I can support that. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!