Thread: Sun acquires MySQL
http://blogs.mysql.com/kaj/sun-acquires-mysql.html/ What does this mean for Sun's support of Postgres? -- Russ.
Russ Brown wrote: > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/ > > What does this mean for Sun's support of Postgres? > Does it matter? :) I am sure OmniTI and Command Prompt will be happy to help any disgruntled customer :) Sincerely, Joshua D. Drake
Joshua Drake shaped the electrons to say:
>
> Russ Brown wrote:
> > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/
> >
> > What does this mean for Sun's support of Postgres?
> >
>
> Does it matter? :) I am sure OmniTI and Command Prompt will be
> happy to help any disgruntled customer :)
Well, in the past year or so Sun seemed to have been moving toward support of PostgreSQL and there was considerable traffic on Great And Subtle Things Beyond My Ken [Jignish Shah, I think, might be the name of the Sun engineer who was working on some issues]. If they own MySQL support for PostgreSQL might be reduced, and perhaps Oracle ? Hard to tell from the blog report. Sun might have some specific use for some aspect of MySQL, or maybe it is part of something bigger. But potentially it could freeze PostgreSQL out of more Sun-centric shops. {locally we use Linux mostly, some Sun, but used to be much more Sun oriented; personally from a Sun background and have a faint fondness for their servers}. I doubt that any entity other than Sun can provide software fixes for issues in Sun kernels that might improve PostgreSQL's performance.
My $0.04 worth (inflation)
Greg Williamson
Senior DBA
GlobeXplorer LLC, a DigitalGlobe company
Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
(My corporate masters made me say this.)
<*may* not *does*, and how the heck could anyone destroy all copies of the original ?!? That's a hoot! my Corporate Masters did not make me say this, too much beer did! >
Russ Brown wrote: > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/ > > What does this mean for Sun's support of Postgres? > Speaking from pure opinion here :) Oracle for example is buying out the little techs that MySQL relies on - BDB and InnoDB. The main company, MySQL AB was all that was left to effectively give them control of MySQL. PostgreSQL obviously doesn't have this risk - No one company holds that much power, and even the -core team is split between the various supporting companies around PostgreSQL. Sun wants to support both. If you wanted to ensure MySQL continued as a company, and you had the money, its not a bad idea really. Sun buys MySQL AB, ensures it continues. I don't see Sun's support of PostgreSQL going away though. I'm sure they have various support contracts out, not to mention various employees working on it. Sun can still contribute equally to PostgreSQL, and it can still make just as much money on PostgreSQL as it does on MySQL. Though PostgreSQL I imagine is cheaper as the community does more of the work, they can just provide the additional support. MySQL they have additional costs as they do more of the development. I'm actually very curious now that Sun owns it, will they change how the community contributes to the database? I personally prefer the PostgreSQL community, joining and contributing to the community I've found to be easier. Then there is - How will Oracle feel about Solaris now? Before Sun just supported the competition, it didn't "own" a direct competitor. Weslee
On Jan 16, 2008 7:19 AM, Russ Brown <pickscrape@gmail.com> wrote: > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/ > > What does this mean for Sun's support of Postgres? I don't see why it should change really, they kind of swim in different waters. What I do think is interesting is that Sun might actually more fully open up MySQL than it has been so far. I.e relax the viral nature of the connect libs. Go back to LGPL licensing on them. Stop trying to collect licensing fees on an open source database. Make the money on consulting instead. It would also be nice to see them do something to streamline the whole 2^n licensing / build model they currently struggle under. Taking a year to fix a fairly innocuous packaging bug, then reintroducing that bug, then squashing it again is not good. It would be nice to see them streamline the development process. Having 4 or 5 active development branches is too chaotic.
How much does Sun currently contribute to the project? Do they have designated coders? -- View this message in context: http://www.nabble.com/Sun-acquires-MySQL-tp14881966p14884994.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Scott Marlowe wrote: > On Jan 16, 2008 7:19 AM, Russ Brown <pickscrape@gmail.com> wrote: >> http://blogs.mysql.com/kaj/sun-acquires-mysql.html/ >> >> What does this mean for Sun's support of Postgres? > > I don't see why it should change really, they kind of swim in different waters. > > What I do think is interesting is that Sun might actually more fully > open up MySQL than it has been so far. I.e relax the viral nature of > the connect libs. To my knowledge that "argument" is long gone, over and no longer relevant. What they do is hold their security fixes back and have official packages etc.. Sincerely, Joshua D. Drake
dvanatta wrote: > How much does Sun currently contribute to the project? Do they have > designated coders? They employ a core member who is not a hacker. They provide some machines etc.. Sincerely, Joshua D. Drake
Joshua D. Drake wrote: > dvanatta wrote: >> How much does Sun currently contribute to the project? Do they have >> designated coders? > > They employ a core member who is not a hacker. > They provide some machines etc.. They contributed a DTrace patch and the Sun hackers can be seen from time to time. They're not just marketing ... -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Joshua D. Drake wrote: >> dvanatta wrote: >>> How much does Sun currently contribute to the project? Do they have >>> designated coders? >> They employ a core member who is not a hacker. >> They provide some machines etc.. > > They contributed a DTrace patch and the Sun hackers can be seen from > time to time. They're not just marketing ... I didn't mean to imply that. I took his question as does Sun have regularly contributing hackers like yourself of AndrewD. Sincerely, Joshua D. Drake
If MySQL goes the way of Java, maybe there isn't too much to worry about. -----Original Message----- From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Weslee Bilodeau Sent: Wednesday, January 16, 2008 10:56 AM To: Russ Brown Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Sun acquires MySQL Russ Brown wrote: > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/ > > What does this mean for Sun's support of Postgres? > Speaking from pure opinion here :) Oracle for example is buying out the little techs that MySQL relies on - BDB and InnoDB. The main company, MySQL AB was all that was left to effectively give them control of MySQL. PostgreSQL obviously doesn't have this risk - No one company holds that much power, and even the -core team is split between the various supporting companies around PostgreSQL. Sun wants to support both. If you wanted to ensure MySQL continued as a company, and you had the money, its not a bad idea really. Sun buys MySQL AB, ensures it continues. I don't see Sun's support of PostgreSQL going away though. I'm sure they have various support contracts out, not to mention various employees working on it. Sun can still contribute equally to PostgreSQL, and it can still make just as much money on PostgreSQL as it does on MySQL. Though PostgreSQL I imagine is cheaper as the community does more of the work, they can just provide the additional support. MySQL they have additional costs as they do more of the development. I'm actually very curious now that Sun owns it, will they change how the community contributes to the database? I personally prefer the PostgreSQL community, joining and contributing to the community I've found to be easier. Then there is - How will Oracle feel about Solaris now? Before Sun just supported the competition, it didn't "own" a direct competitor. Weslee ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
> The main company, MySQL AB was all that was left to effectively give > them control of MySQL. > > PostgreSQL obviously doesn't have this risk - No one company holds that > much power, and even the -core team is split between the various > supporting companies around PostgreSQL. > Is this up to date? http://www.postgresql.org/community/contributors/ I'm asking because I was always told EnterpriseDB employs now 5 out of 7 core committers. Thanks for the clarification. Dirk -- Phone: + 1 (650) 215 3459 Web: http://www.riehle.org
2 out of 7 - which would be Bruce & I. Regards, Dave On 1/16/08, Dirk Riehle <dirk@riehle.org> wrote: > > > The main company, MySQL AB was all that was left to effectively give > > them control of MySQL. > > > > PostgreSQL obviously doesn't have this risk - No one company holds that > > much power, and even the -core team is split between the various > > supporting companies around PostgreSQL. > > > > Is this up to date? > > http://www.postgresql.org/community/contributors/ > > I'm asking because I was always told EnterpriseDB employs now 5 out of 7 > core committers. > > Thanks for the clarification. > > Dirk > > -- > Phone: + 1 (650) 215 3459 > Web: http://www.riehle.org > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- Sent from my mobile device
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 16 Jan 2008 10:25:45 -0800 Dirk Riehle <dirk@riehle.org> wrote: > > > The main company, MySQL AB was all that was left to effectively give > > them control of MySQL. > > > > PostgreSQL obviously doesn't have this risk - No one company holds > > that much power, and even the -core team is split between the > > various supporting companies around PostgreSQL. > > > > Is this up to date? > > http://www.postgresql.org/community/contributors/ > > I'm asking because I was always told EnterpriseDB employs now 5 out > of 7 core committers. What? They do employ more contributors than that (oh and just because they are core doesn't mean they have commit rights). They employ Dave Page and Bruce Momjian who are core members. They also employ Greg Stark and Heikki are very fairly visible contributors. Sincerely, Joshua D. Drake - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHjlBIATb/zqfZUUQRAl1xAJ9S/rm4ex4lC8xTXft5Wm1/qVjg2gCdG4s8 rT/NXbJ2Mad+AMOSNAiQ674= =FlKG -----END PGP SIGNATURE-----
What's up with 3 of the 7 being from Pennsylvania? What's the connection? Dave Page-3 wrote: > > 2 out of 7 - which would be Bruce & I. > > ---------------------------(end of broadcast)--------------------------- > TIP 1: 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 > > -- View this message in context: http://www.nabble.com/Sun-acquires-MySQL-tp14881966p14895300.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 16 Jan 2008 13:23:35 -0800 (PST) dvanatta <dvanatta@yahoo.com> wrote: > > What's up with 3 of the 7 being from Pennsylvania? What's the > connection? Its the closest the cult of the elephant will get to jersey. Joshua D. Drake - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHjneZATb/zqfZUUQRAsjKAKCj3xpZ8NBEvMYKmmDJdiu/6Y50PQCeI2fr w+d0U+qn8mmvl2ylK2LeI0Q= =nCyQ -----END PGP SIGNATURE-----
In response to dvanatta <dvanatta@yahoo.com>: > > What's up with 3 of the 7 being from Pennsylvania? What's the connection? Well, as everyone knows, Pennsylvania is a haven for brilliant people. In fact, simply living in Pennsylvania makes you smarter. -- Bill Moran http://www.potentialtech.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 16 Jan 2008 16:29:01 -0500 Bill Moran <wmoran@potentialtech.com> wrote: > In response to dvanatta <dvanatta@yahoo.com>: > > > > > What's up with 3 of the 7 being from Pennsylvania? What's the > > connection? > > Well, as everyone knows, Pennsylvania is a haven for brilliant > people. In fact, simply living in Pennsylvania makes you smarter. Then why did Ben Frankly attach a key to a kite in the middle of a thunderstorm? Joshua D. Drake - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHjnlTATb/zqfZUUQRAt2HAJ4xJCGVrGnD9ydhSKkg8twAvZaM/QCfUJ7v VDgpjoFCwcDJryk6+WxZ1CI= =/IOr -----END PGP SIGNATURE-----
And this is why I live in pa, but make the trek in to the netherworld known as new jersey. :D On 1/16/08, Bill Moran <wmoran@potentialtech.com> wrote: > In response to dvanatta <dvanatta@yahoo.com>: > > > > > What's up with 3 of the 7 being from Pennsylvania? What's the connection? > > Well, as everyone knows, Pennsylvania is a haven for brilliant > people. In fact, simply living in Pennsylvania makes you smarter. > > -- > Bill Moran > http://www.potentialtech.com > > ---------------------------(end of broadcast)--------------------------- > TIP 1: 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 > -- Kindest Regards, Geoff
> Russ Brown wrote: > > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/ > > > > What does this mean for Sun's support of Postgres? > > So why not go directly to the "source", Sun itself, and ask them? Someone like Bruce should just knock on the door and ask. Then you can evaluate the answer. Either a lie, the truth, or somewhere in-between, and the answer may only have a certain "shelf-life", for what is true today in the tech industry is false later. ..Otto
Sounds reasonable, but what one manager answers today is subject to be changed by another tomorrow. On 1/16/08, Otto Hirr <otto.hirr@olabinc.com> wrote: > > Russ Brown wrote: > > > http://blogs.mysql.com/kaj/sun-acquires-mysql.html/ > > > > > > What does this mean for Sun's support of Postgres? > > > > > So why not go directly to the "source", Sun itself, and ask them? > > Someone like Bruce should just knock on the door and ask. > > Then you can evaluate the answer. Either a lie, the truth, or somewhere > in-between, and the answer may only have a certain "shelf-life", for what is > true today in the tech industry is false later. > > ..Otto > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org/ > -- Kindest Regards, Geoff
> From: Geoffrey Gowey > Sounds reasonable, but what one manager answers today is subject to be > changed by another tomorrow. The intent is to get out in the open their "official" statement. That in turn may create a discussion inside Sun that maynot have taken place. If postgres community does not like the stand, then lobby to change it. Like you say, nothing either in time or by individualis forever locked in. If the postgres community likes it, then be sure to continue to support Sun so that they continue in that direction. If theycome out with a favorable strategy or had a planned strategy but kept it to themselves and postgres disses them, thenthey may take their toys and decide to play in other ways. But get it out in the open as much as can be done. Simple. Then you know where they stand/don't-stand/or remain mute. Then you can take further action. Rumors/opinions are just that. Postgres needs to have an "official spokesman" make a request at a "very important top official" that is responsible forthe acquisition. ..Otto
Joshua D. Drake wrote: > dvanatta <dvanatta@yahoo.com> wrote: >> What's up with 3 of the 7 being from Pennsylvania? What's the >> connection? > > Its the closest the cult of the elephant will get to jersey. Whoa now, them's fightin' words. Come on over and you me, Tony, Paulie and Silvio will have a little chat.
--- Bill Moran <wmoran@potentialtech.com> wrote: > In response to dvanatta <dvanatta@yahoo.com>: > > > > > What's up with 3 of the 7 being from Pennsylvania? > What's the connection? > > Well, as everyone knows, Pennsylvania is a haven for > brilliant > people. In fact, simply living in Pennsylvania > makes you smarter. > Does it count if I lived there for a year many many years ago? ;-) Ted
On 16/01/2008 23:10, Ted Byers wrote: > Does it count if I lived there for a year many many > years ago? ;-) ...or if I visited for a day or two in 1986? ;-) Ray. --------------------------------------------------------------- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland rod@iol.ie ---------------------------------------------------------------
On Jan 16, 2008, at 4:02 PM, Otto Hirr wrote: >> Postgres needs to have an "official spokesman" make a request at a >> "very important top official" that is responsible for the >> acquisition. > > ..Otto Given that Josh Berkus works for Sun, I'd say we already have that. Erik Jones DBA | Emma® erik@myemma.com 800.595.4401 or 615.292.5888 615.292.0777 (fax) Emma helps organizations everywhere communicate & market in style. Visit us online at http://www.myemma.com
Otto Hirr wrote: > Postgres needs to have an "official spokesman" make a request at a "very > important top official" that is responsible for the acquisition. Postgres doesn't need to do anything, because the matter at hand does not concern Postgres, and I think we shouldn't spend our energy making it so. Nevertheless, I suggest you follow Josh Berkus's blog, which is as close as you will get to someone important from Postgres having access to someone important at Sun. -- Peter Eisentraut http://developer.postgresql.org/~petere/
> > IsMySQLa direct competitor to Oracle? For the people who usemysql, > > mostly smaller websites, oracle is not a realistic option. > > Smaller? Did you mean Larger? > I think what I mean is less mission critical. I have never heard of a bank using MySQL as their main database system. My point is, it does not seem to me that Oracle and MySQL compete head to head. Most people who use Oracle would not consider MySQL for anything critical. And most people who use MySQL would not consider Oracle. For now, I think the two products target different markets. Of course, that could change. Before Sun acquired MySQL, I suspected that MySQL would be squeezed between PostgreSQL and SQLite.
Good Morning Walter dont forget MySQL also has support for simple commands such as show databases show tables support for compiling and execution of Procedures in Postgres is nonexistent 99% of SQL code in either Oracle and MySQL DB's are written in Procedures..trying to port that to Postgres is a very long and tedious uphill climb Comments? Martin ----- Original Message ----- From: "walterbyrd" <walterbyrd@iname.com> To: <pgsql-general@postgresql.org> Sent: Sunday, January 20, 2008 9:34 AM Subject: Re: [GENERAL] Sun acquires MySQL > > > IsMySQLa direct competitor to Oracle? For the people who usemysql, > > > mostly smaller websites, oracle is not a realistic option. > > > > Smaller? Did you mean Larger? > > > > I think what I mean is less mission critical. I have never heard of a > bank using MySQL as their main database system. > > My point is, it does not seem to me that Oracle and MySQL compete head > to head. Most people who use Oracle would not consider MySQL for > anything critical. And most people who use MySQL would not consider > Oracle. For now, I think the two products target different markets. Of > course, that could change. > > Before Sun acquired MySQL, I suspected that MySQL would be squeezed > between PostgreSQL and SQLite. > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
On Sun, Jan 20, 2008 at 11:33:43AM -0500, Martin Gainty wrote: > dont forget MySQL also has support for simple commands such as > show databases Type: \d > show tables Type: \l Not sure how it could be any simpler... > support for compiling and execution of Procedures in Postgres is nonexistent > 99% of SQL code in either Oracle and MySQL DB's are written in > Procedures..trying to port that to Postgres is a very long and tedious > uphill climb Sorry? PostgreSQL supports SPs in several languages.. What exactly are you referring to here? -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Those who make peaceful revolution impossible will make violent revolution inevitable. > -- John F Kennedy
Attachment
On Sun, 20 Jan 2008 17:46:19 +0100 Martijn van Oosterhout <kleptog@svana.org> wrote: > > support for compiling and execution of Procedures in Postgres is > > nonexistent 99% of SQL code in either Oracle and MySQL DB's are > > written in Procedures..trying to port that to Postgres is a very > > long and tedious uphill climb > > Sorry? PostgreSQL supports SPs in several languages.. What exactly are > you referring to here? Technically postgresql doesn't support SPs, we support functions. I am not exactly sure what the difference is but I can tell you that in terms of Oracle we are pretty far behind (plpgsql vs plsql). Sincerely, Joshua D. Drake
Attachment
Hello > > support for compiling and execution of Procedures in Postgres is nonexistent > 99% of SQL code in either Oracle and MySQL DB's are written in > Procedures..trying to port that to Postgres is a very long and tedious > uphill climb > true compilation is necessary only for some cases (note: MySQL stored procedures are not compiled too ~ PostgreSQL has similar language plpgpsm with little bit faster execution (http://www.pgsql.cz/index.php/SQL/PSM_Manual ). When plpgsql is potentially slow, you can use perl or write own custom function in C, what is simpler than with Oracle. Regards Pavel Stehule
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> dont forget MySQL also has support for simple commands such as >> show databases > Type: \d >> show tables > Type: \l > > Not sure how it could be any simpler... Simpler, no, but it could be a lot more intuitive. I think having psql recognize /^help/i would be a nice first step. Hmm, off to write a quick patch... - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200801201225 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFHk4pOvJuQZxSWSsgRAwLMAKDRHVWRpAW6sckQB6ZwzquRFx6cnACcCfHW 8qiiJhNNIOvCyDqe3wefYTQ= =D2T3 -----END PGP SIGNATURE-----
On Sun, 20 Jan 2008 17:54:01 -0000 "Greg Sabino Mullane" <greg@turnstep.com> wrote: > > Not sure how it could be any simpler... > > Simpler, no, but it could be a lot more intuitive. I think having > psql recognize /^help/i would be a nice first step. Hmm, off to > write a quick patch... +1 Joshua D. Drake
Attachment
On Sun, Jan 20, 2008 at 05:54:01PM -0000, Greg Sabino Mullane wrote:
> Simpler, no, but it could be a lot more intuitive. I think having
> psql recognize /^help/i would be a nice first step. Hmm, off to
> write a quick patch...
When you start psql you get the nice message:
---
Welcome to psql 8.1.11, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit
I think people should be able to read and know that \? is how to get
help.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Those who make peaceful revolution impossible will make violent revolution inevitable.
> -- John F Kennedy
Attachment
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 20 Jan 2008 19:08:37 +0100 Martijn van Oosterhout <kleptog@svana.org> wrote: > Type: \copyright for distribution terms > \h for help with SQL commands > \? for help with psql commands > \g or terminate with semicolon to execute query > \q to quit > > I think people should be able to read and know that \? is how to get > help. If only it were that simple. I teach. I teach that exact statement you say above. Guess what the two most often things happen in class. How do I get help again? Why isn't my query executing? (they always forget the ;). \? Is counter intuitive. There is zero valid argument against that. Yes they should be able to read the screen. There is zero valid argument against that. Most won't. Worse there are two ways to get help... \h and \? and they aren't the same thing. I don't have a solution for that one. I think adding help to the psql prompt is a very sane way to help people. It is human. Sincerely, Joshua D. Drake > > Have a nice day, - -- The PostgreSQL Company: Since 1997, http://www.commandprompt.com/ Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHk5WOATb/zqfZUUQRAnAHAJwIVdrdHZ2lMl9WsZlPrhDnopK9gwCfUNCo qfYRfdbNoUp6oi3okZkCCkk= =YCzE -----END PGP SIGNATURE-----
On 20/01/2008, Greg Sabino Mullane <greg@turnstep.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > >> dont forget MySQL also has support for simple commands such as > >> show databases > > Type: \d > >> show tables > > Type: \l > > > > Not sure how it could be any simpler... > > Simpler, no, but it could be a lot more intuitive. I think having > psql recognize /^help/i would be a nice first step. Hmm, off to > write a quick patch... > I unlike it. It inconsistent! all metacommands or psql commands starts with backslash. regards Pavel Stehule > - -- > Greg Sabino Mullane greg@turnstep.com > PGP Key: 0x14964AC8 200801201225 > http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 > -----BEGIN PGP SIGNATURE----- > > iD8DBQFHk4pOvJuQZxSWSsgRAwLMAKDRHVWRpAW6sckQB6ZwzquRFx6cnACcCfHW > 8qiiJhNNIOvCyDqe3wefYTQ= > =D2T3 > -----END PGP SIGNATURE----- > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: 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 love Postgresql to death, it's one of the shining stars of the Open Source movement IMHO. It's rock solid, crashes less frequently than Oracle in my experience, and does almost everything I could ask of it (granted - I don't ask much often, just simple things like consistent behaviour, which seems to elude many other products). My one biggest bone to pick with Postgresql is that stored procedures are not compiled. It makes writing anything but the most trivial things in plpgsql stupid because it will slow the crap out of your queries. For example: I wrote a simple function to return the distance between two lat longs in plpgsql. Not only did it choke on values that were part of a valid domain when calling acos() (I have a list of them someplace that I keep meaning to post as it seems like a really bad bug), it was slow. I re-implemented in C and it was 8-12 times faster, and didn't error out on acos for the same values. Expecting DBAs to be able to write functions in C IMHO is a bit unrealistic. I am far from a typical DBA, I've met precious few Oracle DBAs who could write functions in C. Trying to implement good database code that is atomic and makes good use of functions in Postgresql is an uphill battle because they slow the database down so much.
On Jan 20, 2008 12:04 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
This seems like a fallacious claim as MySQL only introduced procedures in 5.0 and their implementation was incomplete and has been kind of incremental since 5.0 and still isn't complete, whereas plpgsql in Postgresql is a well advanced implementation that works very well (Other than speed). Given that it is also possible to implement functions in Perl, C, Java and Python, it seems that you can achieve pretty much anything with a function in Postgresql, which is not true in Oracle or MySQL. Oracle makes extensive use of views and sql files, but not so much stored procs in the core distro if I remember rightly, certainly not 99%.
True compilation is necessary for all cases if you care about scalability, which ultimately everybody does as they will continue to run more and more sites/databases on a set of servers until the CPU/IO limit is reached - it's called business - you maximize resources. Plpgsql's lack of compilation dramatically lowers that threshold, which means smaller profits for hosters of Postgresql and serious limits on OLTP scalability when plpgsql functions are utilized. Plus do you really want your hosted people writing functions in C for your Postgresql? Hell, _I_ don't want to write functions in C for Postgresql much, plpgsql is much less error prone and much easier to deal with.
If I had to ask the Postgresql people to put one thing on the wish list for the next major release it would be compiled functions, it's the one thing my apps would benefit the most from as I like keeping data integrity, and functions help me achieve that with elegance (I could tell you some stories about data integrity with data feeds from other companies who clearly didn't actually hire a DBA to design their database implementation, every row in it's own transaction because you never know when it's going to violate foreign key constraints, totally sucktastic). (The other thing would be cache management, I know that my system would benefit hugely from being me being able to direct certain tables to remain in memory regardless of MRU data - It seems like something might be possible with RAM disks but how do you sync it back to physical disk in a reliable way so that when your machine dies your data doesn't buy the farm?).
Alex
Hello
>
> support for compiling and execution of Procedures in Postgres is nonexistent
> 99% of SQL code in either Oracle and MySQL DB's are written in
> Procedures..trying to port that to Postgres is a very long and tedious
> uphill climb
>
This seems like a fallacious claim as MySQL only introduced procedures in 5.0 and their implementation was incomplete and has been kind of incremental since 5.0 and still isn't complete, whereas plpgsql in Postgresql is a well advanced implementation that works very well (Other than speed). Given that it is also possible to implement functions in Perl, C, Java and Python, it seems that you can achieve pretty much anything with a function in Postgresql, which is not true in Oracle or MySQL. Oracle makes extensive use of views and sql files, but not so much stored procs in the core distro if I remember rightly, certainly not 99%.
true compilation is necessary only for some cases (note: MySQL stored
procedures are not compiled too ~ PostgreSQL has similar language
plpgpsm with little bit faster execution
(http://www.pgsql.cz/index.php/SQL/PSM_Manual ). When plpgsql is
potentially slow, you can use perl or write own custom function in C,
what is simpler than with Oracle.
Anyone who is using Perl for something that needs to be fast is seriously misguided. My benchmarking to date shows that Perl is the slowest of the mainstream second/third gen languages. Even python is faster and python can be a dog (Having said that, python 3 looks to be about twice as fast though which is quite an improvement)
True compilation is necessary for all cases if you care about scalability, which ultimately everybody does as they will continue to run more and more sites/databases on a set of servers until the CPU/IO limit is reached - it's called business - you maximize resources. Plpgsql's lack of compilation dramatically lowers that threshold, which means smaller profits for hosters of Postgresql and serious limits on OLTP scalability when plpgsql functions are utilized. Plus do you really want your hosted people writing functions in C for your Postgresql? Hell, _I_ don't want to write functions in C for Postgresql much, plpgsql is much less error prone and much easier to deal with.
If I had to ask the Postgresql people to put one thing on the wish list for the next major release it would be compiled functions, it's the one thing my apps would benefit the most from as I like keeping data integrity, and functions help me achieve that with elegance (I could tell you some stories about data integrity with data feeds from other companies who clearly didn't actually hire a DBA to design their database implementation, every row in it's own transaction because you never know when it's going to violate foreign key constraints, totally sucktastic). (The other thing would be cache management, I know that my system would benefit hugely from being me being able to direct certain tables to remain in memory regardless of MRU data - It seems like something might be possible with RAM disks but how do you sync it back to physical disk in a reliable way so that when your machine dies your data doesn't buy the farm?).
On 21/01/2008, Alex Turner <armtuk@gmail.com> wrote: > I love Postgresql to death, it's one of the shining stars of the Open Source > movement IMHO. It's rock solid, crashes less frequently than Oracle in my > experience, and does almost everything I could ask of it (granted - I don't > ask much often, just simple things like consistent behaviour, which seems to > elude many other products). My one biggest bone to pick with Postgresql is > that stored procedures are not compiled. It makes writing anything but the > most trivial things in plpgsql stupid because it will slow the crap out of > your queries. For example: I wrote a simple function to return the distance > between two lat longs in plpgsql. Not only did it choke on values that were > part of a valid domain when calling acos() (I have a list of them someplace > that I keep meaning to post as it seems like a really bad bug), it was slow. > I re-implemented in C and it was 8-12 times faster, and didn't error out on > acos for the same values. Expecting DBAs to be able to write functions in C > IMHO is a bit unrealistic. I am far from a typical DBA, I've met precious > few Oracle DBAs who could write functions in C. Trying to implement good > database code that is atomic and makes good use of functions in Postgresql > is an uphill battle because they slow the database down so much. Usability of plpgsql depend on case. There are some case where plpgsql is useless: http://www.pgsql.cz/index.php/PL/pgSQL_%28en%29#When_is_PL.2FpgSQL_not_applicable when you use plpgsql as glue of SQL statements, then speed of plpgsql >> speed of SQL statements and there isn't problem. Your example is real and I understand well, but bottleneck isn't in interpretation, is it in evaluation of basic types, where C do this work simply and fast and plpgsql call SQL expression evaluator. I am not sure if its possible to write compiler for all supported platforms. I thinking about plpgsql->c translator with some intelligence for detecting some simply operations. Any sponsors? Regards Pavel Stehule
On Mon, Jan 21, 2008 at 02:47:32AM -0500, Alex Turner wrote: > My one biggest bone to pick with Postgresql is > that stored procedures are not compiled. I'm not going go into this since in my experience they are fast enough and I don't know enough of your context to decide if the problem has been correctly diagnosed. plpgsql is not the fastest language supprted by postgres. > It makes writing anything but the > most trivial things in plpgsql stupid because it will slow the crap out of > your queries. For example: I wrote a simple function to return the distance > between two lat longs in plpgsql. Wrong tool for the job? If it's a single statement you should be using lang 'sql' which would allow it to be inlined in your queries. I've personally not found plpgsql to be so slow. In this case, I would simply install postgis and you get all the speed you need: # select distance_sphere( makepoint(0,0), makepoint(0,180)); distance_sphere ------------------ 20015045.5917028 (1 row) > Not only did it choke on values that were > part of a valid domain when calling acos() (I have a list of them someplace > that I keep meaning to post as it seems like a really bad bug), it was > slow. Please report such bugs, since no-one else has seen this problem... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Those who make peaceful revolution impossible will make violent revolution inevitable. > -- John F Kennedy
Attachment
On Jan 21, 2008 2:47 AM, Alex Turner <armtuk@gmail.com> wrote: > I re-implemented in C and it was 8-12 times faster, and didn't error out on > acos for the same values. Expecting DBAs to be able to write functions in C acos error on distance function is rounding issue, easy fix if you had to do it this way (although this code really belongs in C). > IMHO is a bit unrealistic. I am far from a typical DBA, I've met precious > few Oracle DBAs who could write functions in C. Trying to implement good > database code that is atomic and makes good use of functions in Postgresql > is an uphill battle because they slow the database down so much. While doing things like calculating distance are better handled in languages like C, it is relatively trivial to wrap C libraries with SQL and call them from in side sql or pl/pgsql procedures. Most of the database functions I write are simply chaining SQL statements together for presentation to the application or more complex queries. pl/pgsql is very good at this...unless you know _exactly_ what you are doing, writing these kinds of functions in C, which requires use of SPI, will not get you anything on the performance side (and could actually hurt, if you don't go through all the effort of plan management). In other words, pl/pgsql's speed disadvantages only matter if a significant portion of the work is in doing things other than executing queries and handling the results. Certainly, these types of problems come up, but such cases are simply out of the scope of the intended purpose of the language and there are many techniques dealing with these problems. On the other hand, pl/pgsql is extremely easy to write and debug, especially when running static sql. IMO, it is an absolute must for any PostgreSQL DBA to master the language as well as be aware of its limitations. merlin
Merlin Moncure wrote: > On Jan 21, 2008 2:47 AM, Alex Turner <armtuk@gmail.com> wrote: > In other words, pl/pgsql's speed disadvantages only matter if a > significant portion of the work is in doing things other than > executing queries and handling the results. Certainly, these types of > problems come up, but such cases are simply out of the scope of the > intended purpose of the language and there are many techniques dealing > with these problems. On the other hand, pl/pgsql is extremely easy to > write and debug, especially when running static sql. IMO, it is an > absolute must for any PostgreSQL DBA to master the language as well as > be aware of its limitations. > > merlin > Perhaps it would be useful to have a page in the documentation that provides a brief comparison between the available pl languages (including plpgsql and sql) and gives suggestions on the best one (or ones) for given use cases? -- Russ.
On Mon, 21 Jan 2008 08:01:49 -0600 Russ Brown <pickscrape@gmail.com> wrote: > Perhaps it would be useful to have a page in the documentation that > provides a brief comparison between the available pl languages > (including plpgsql and sql) and gives suggestions on the best one > (or ones) for given use cases? It'd be very appreciated. I tried to read this: http://www.pgsql.cz/index.php/PL/pgSQL_(en)#When_is_PL.2FpgSQL_not_applicable But I'm not sure I really grasped it. Some comparison/examples more may help. BTW today pg 8.3-rc2 reached Debian sid amd64 and I took a chance to see what was available... and there is support for a *lot* of languages now. I started to develop a lot of functions code thinking that pgsql was the nearest thing to the metal after plain sql and after these post I was wondering if python (or ruby??) would have made a better choice. My main concern when I chose the function route was limiting the number of connections and hiding the underlying structure of the DB to the client application. -- Ivan Sergio Borgonovo http://www.webthatworks.it
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> when you use plpgsql as glue of SQL statements, then speed of plpgsql
> speed of SQL statements and there isn't problem. Your example is
> real and I understand well, but bottleneck isn't in interpretation, is
> it in evaluation of basic types, where C do this work simply and fast
> and plpgsql call SQL expression evaluator. I am not sure if its
> possible to write compiler for all supported platforms. I thinking
> about plpgsql->c translator with some intelligence for detecting some
> simply operations. Any sponsors?
That's probably not worth the amount of effort it would take.
The bottom line is: if you're doing computationally expensive
non-SQL-query operations, plpgsql is simply the wrong language for the
job ... and it's not like there are not plenty of others to choose from.
I'd expect plperl or even pltcl to be faster for such things (I have no
idea about the speed of other scripting languages such as python or
ruby). Or pl/java. Also, if what you're doing fits within its
capabilities, pl/R is an interesting alternative.
regards, tom lane
Tom Lane wrote: > The bottom line is: if you're doing computationally expensive > non-SQL-query operations, plpgsql is simply the wrong language for the > job ... and it's not like there are not plenty of others to choose from. > I'd expect plperl or even pltcl to be faster for such things (I have no > idea about the speed of other scripting languages such as python or > ruby). Or pl/java. Also, if what you're doing fits within its > capabilities, pl/R is an interesting alternative. Unfortunately, I think the stored procedure implementation in PG itself introduces significant overhead. See thread "Writing most code in Stored Procedures" from August 2007. I converted an application from that BigDBMS we are not allowed to mention to PG. Code is Java, stored procs were written in PL/Java. On the exact same hardware, I couldn't get any where near the throughput I was getting in BigDBMS. The procs are trivial - just wrappers for insert statements. After I exhausted all alternatives, I replaced the stored proc invocation in the code with inserts. Then, PG was able to achieve the same throughput as BigDBMS. -- Guy Rouillier
Guy Rouillier <guyr-ml1@burntmail.com> writes:
> Unfortunately, I think the stored procedure implementation in PG itself
> introduces significant overhead. See thread "Writing most code in
> Stored Procedures" from August 2007. I converted an application from
> that BigDBMS we are not allowed to mention to PG. Code is Java, stored
> procs were written in PL/Java. On the exact same hardware, I couldn't
> get any where near the throughput I was getting in BigDBMS. The procs
> are trivial - just wrappers for insert statements. After I exhausted
> all alternatives, I replaced the stored proc invocation in the code with
> inserts. Then, PG was able to achieve the same throughput as BigDBMS.
I doubt that what you were measuring there was either procedure call
overhead or java computational speed; more likely it was the cost of
calling back out of java, through pl/java's JDBC emulation, down through
SPI, to re-execute the same INSERT that you then decided to execute
directly. In particular, if pl/java's JDBC doesn't know anything about
caching query plans, performance for simple inserts could be expected to
go into the tank just because of that. (Whether it actually does or
not, I have no idea --- but I would expect it to be a lot less mature
than the mainstream JDBC driver for PG, and that took years to get
smart about prepared queries ...)
Without knowing where the bottleneck actually is, it's unreasonable to
assume that it would hurt a different use-case.
regards, tom lane
On Monday 21 January 2008 04:47:40 pm Tom Lane wrote: > Guy Rouillier <guyr-ml1@burntmail.com> writes: > > Unfortunately, I think the stored procedure implementation in PG itself > > introduces significant overhead. See thread "Writing most code in > > Stored Procedures" from August 2007. I converted an application from > > that BigDBMS we are not allowed to mention to PG. Code is Java, stored > > procs were written in PL/Java. On the exact same hardware, I couldn't > > get any where near the throughput I was getting in BigDBMS. The procs > > are trivial - just wrappers for insert statements. After I exhausted > > all alternatives, I replaced the stored proc invocation in the code with > > inserts. Then, PG was able to achieve the same throughput as BigDBMS. > > I doubt that what you were measuring there was either procedure call > overhead or java computational speed; more likely it was the cost of > calling back out of java, through pl/java's JDBC emulation, down through > SPI, to re-execute the same INSERT that you then decided to execute > directly. In particular, if pl/java's JDBC doesn't know anything about > caching query plans, performance for simple inserts could be expected to > go into the tank just because of that. (Whether it actually does or > not, I have no idea --- but I would expect it to be a lot less mature > than the mainstream JDBC driver for PG, and that took years to get > smart about prepared queries ...) > > Without knowing where the bottleneck actually is, it's unreasonable to > assume that it would hurt a different use-case. Tom, I have read several of your post on store procedure performance. Why not give us your take on what works and what does not. -- John Fabiani
On Mon, 21 Jan 2008 21:31:23 -0800 johnf <jfabiani@yolo.com> wrote: > On Monday 21 January 2008 04:47:40 pm Tom Lane wrote: > > I doubt that what you were measuring there was either procedure > > call overhead or java computational speed; more likely it was the > > cost of calling back out of java, through pl/java's JDBC > > emulation, down through SPI, to re-execute the same INSERT that > > you then decided to execute directly. In particular, if > > pl/java's JDBC doesn't know anything about caching query plans, > > performance for simple inserts could be expected to go into the > > tank just because of that. (Whether it actually does or not, I > > have no idea --- but I would expect it to be a lot less mature > > than the mainstream JDBC driver for PG, and that took years to > > get smart about prepared queries ...) > > Without knowing where the bottleneck actually is, it's > > unreasonable to assume that it would hurt a different use-case. > Tom, > I have read several of your post on store procedure performance. > Why not give us your take on what works and what does not. Yep, the more I read, the more I get confused. Java loading overhead is a common myth (I can't say if true or false), and what Tom writes above can find a tentative place in my mind. But still then I can't understand where plsql should or shouldn't be used. I really would enjoy to see some general guideline on how to chose. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Jan 22, 2008 2:24 AM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote: > > > I doubt that what you were measuring there was either procedure > > > call overhead or java computational speed; more likely it was the > > > cost of calling back out of java, through pl/java's JDBC > > > emulation, down through SPI, to re-execute the same INSERT that > > > you then decided to execute directly. In particular, if > > > pl/java's JDBC doesn't know anything about caching query plans, > > > performance for simple inserts could be expected to go into the > > > tank just because of that. (Whether it actually does or not, I > > > have no idea --- but I would expect it to be a lot less mature > > > than the mainstream JDBC driver for PG, and that took years to > > > get smart about prepared queries ...) > > > > Without knowing where the bottleneck actually is, it's > > > unreasonable to assume that it would hurt a different use-case. > > > Tom, > > I have read several of your post on store procedure performance. > > Why not give us your take on what works and what does not. > > Yep, the more I read, the more I get confused. > Java loading overhead is a common myth (I can't say if true or false), > and what Tom writes above can find a tentative place in my mind. > But still then I can't understand where plsql should or shouldn't be > used. It's fairly trivial to test performance of functions vs. raw statements, or just about anything going on with the server. The benchmarking tool, pgbench, allows custom sql which is great for things like this. It would have shown you that functions themselves are not the reason why your application was not running quickly. My seat of the pants guess (I don't do java) was that your problem was in the jdbc driver somewhere. When using a high level database framework like jdbc or ado.net, it can be difficult to figure out exactly what is going on with the database at times...I tend to avoid them. merlin
>
> Yep, the more I read, the more I get confused.
> Java loading overhead is a common myth (I can't say if true or false),
> and what Tom writes above can find a tentative place in my mind.
> But still then I can't understand where plsql should or shouldn't be
> used.
>
> I really would enjoy to see some general guideline on how to chose.
>
1. use procedure lot of SQL statements --> use plpgsql
2. procedure needs some untrusted functionality -> use untrusted language
3. procedure contains only expressions
3.a) isn't too much important --> use plpgsql don't forgot IMMUTABLE flag
3.b) is important and is bottleneck --> try perl
3.c) is most important or is wide used --> use C
3.d) is simply implemented in C (some time, string fce) --> use C
learn some trick:
create or replace function list(int)
returns varchar as $$
declare s varchar = '';
begin
for i in 1..$1 loop
s := s || '<item>' || i || '</item>';
end loop;
return s;
end; $$ language plpgsql;
postgres=# select list(10);
list
-----------------------------------------------------------------------------------------------------------------------------------------------
<item>1</item><item>2</item><item>3</item><item>4</item><item>5</item><item>6</item><item>7</item><item>8</item><item>9</item><item>10</item>
(1 row)
Time: 0,927 ms -- well
number, time
100, 5ms
1000, 75ms ... usable
10000, 4s ... slow
so if I use fce list with param < 1000 I can use plpgsql without any
problems. With bigger value I have problem. But I forgot IMMUTABLE,
ook try again:
100, 4ms
1000, 70ms
10000, 3.8s ok IMMUTABLE doesn't help here
what is bottleneck? FOR?
create or replace function list(int)
returns varchar as $$
declare s varchar = '';
begin
for i in 1..$1 loop
perform '<item>' || i || '</item>';
end loop;
return s;
end; $$ language plpgsql immutable;
10000, 443 ms ..
bottleneck is in repeated assign s := s || ..
I will try trick:
create or replace function list(int)
returns varchar as $$
begin
return array_to_string(array(select '<item>' || i || '</item>'
from generate_series(1, $1) g(i)), '');
end$$ language plpgsql immutable;
test
100, 1.3ms
1000, 7.64ms
10000, 63ms -- nice I don't need C
100000, 350ms
Regards
Pavel Stehule
> thanks
>
> --
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org/
>
Pavel Stehule wrote: > > ... > > bottleneck is in repeated assign s := s || .. > > I will try trick: > > create or replace function list(int) > returns varchar as $$ > begin > return array_to_string(array(select '<item>' || i || '</item>' > from generate_series(1, $1) g(i)), ''); > end$$ language plpgsql immutable; > > test > 100, 1.3ms > 1000, 7.64ms > 10000, 63ms -- nice I don't need C > 100000, 350ms > Regards > > Pavel Stehule > That's some trick! Thanks for the lessons, Pavel. b