Re: [GENERAL] Sun acquires MySQL
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 [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [GENERAL] Sun acquires MySQL
On 21/01/2008, Alex Turner [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Sun acquires MySQL
On Jan 21, 2008 2:47 AM, Alex Turner [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Sun acquires MySQL
Merlin Moncure wrote: On Jan 21, 2008 2:47 AM, Alex Turner [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Sun acquires MySQL
On Mon, 21 Jan 2008 08:01:49 -0600 Russ Brown [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Sun acquires MySQL
Pavel Stehule [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Sun acquires MySQL
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Sun acquires MySQL
Guy Rouillier [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Sun acquires MySQL
On Monday 21 January 2008 04:47:40 pm Tom Lane wrote: Guy Rouillier [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
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
Re: [GENERAL] Sun acquires MySQL
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 [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [GENERAL] Sun acquires MySQL
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 [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Sun acquires MySQL
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Sun acquires MySQL
On Sun, 20 Jan 2008 17:46:19 +0100 Martijn van Oosterhout [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [GENERAL] Sun acquires MySQL
-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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Sun acquires MySQL
On Sun, 20 Jan 2008 17:54:01 - Greg Sabino Mullane [EMAIL PROTECTED] 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 signature.asc Description: PGP signature
Re: [GENERAL] Sun acquires MySQL
On Sun, Jan 20, 2008 at 05:54:01PM -, 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 [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [GENERAL] Sun acquires MySQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 20 Jan 2008 19:08:37 +0100 Martijn van Oosterhout [EMAIL PROTECTED] 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- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Sun acquires MySQL
On 20/01/2008, Greg Sabino Mullane [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Sun acquires MySQL
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 [EMAIL PROTECTED] wrote: 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?). Alex
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? Does it matter? :) I am sure OmniTI and Command Prompt will be happy to help any disgruntled customer :) Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Sun acquires MySQL
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!
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
Re: [GENERAL] Sun acquires MySQL
On Jan 16, 2008 7:19 AM, Russ Brown [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Sun acquires MySQL
Scott Marlowe wrote: On Jan 16, 2008 7:19 AM, Russ Brown [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Sun acquires MySQL
If MySQL goes the way of Java, maybe there isn't too much to worry about. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Sun acquires MySQL
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
Re: [GENERAL] Sun acquires MySQL
2 out of 7 - which would be Bruce I. Regards, Dave On 1/16/08, Dirk Riehle [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Sun acquires MySQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 16 Jan 2008 10:25:45 -0800 Dirk Riehle [EMAIL PROTECTED] 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- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Sun acquires MySQL
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 [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Sun acquires MySQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 16 Jan 2008 13:23:35 -0800 (PST) dvanatta [EMAIL PROTECTED] 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- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Sun acquires MySQL
In response to dvanatta [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Sun acquires MySQL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 16 Jan 2008 16:29:01 -0500 Bill Moran [EMAIL PROTECTED] wrote: In response to dvanatta [EMAIL PROTECTED]: 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- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Sun acquires MySQL
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 [EMAIL PROTECTED] wrote: In response to dvanatta [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Kindest Regards, Geoff ---(end of broadcast)--- TIP 6: explain analyze is your friend
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? 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/
Re: [GENERAL] Sun acquires MySQL
Sounds reasonable, but what one manager answers today is subject to be changed by another tomorrow. On 1/16/08, Otto Hirr [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Sun acquires MySQL
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 may not 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 individual is 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 they come out with a favorable strategy or had a planned strategy but kept it to themselves and postgres disses them, then they 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 for the acquisition. ..Otto ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Sun acquires MySQL
Joshua D. Drake wrote: dvanatta [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Sun acquires MySQL
--- Bill Moran [EMAIL PROTECTED] wrote: In response to dvanatta [EMAIL PROTECTED]: 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Sun acquires MySQL
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 [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Sun acquires MySQL
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® [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Sun acquires MySQL
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/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
