Slashdot Mirror
Sun Announces Support for PostgreSQL
jadavis writes "Sun announces 24x7 support for PostgreSQL on Solaris 10. From the article: 'Today Sun announced that it will be integrating the Postgres open source data base into the Solaris 10 OS and providing world-wide 24x7 support for customers who wish to develop and deploy open source database solutions into their enterprise environments. Sun is working with the PostgresSQL community to take advantage of the advanced technologies in the Solaris 10 OS, such as Predictive Self-Healing, Solaris Containers and Solaris Dynamic Tracing (DTrace).'"
...the advanced technologies in the Solaris 10 OS, such as Predictive Self-Healing...
Yes, this is a technology that is able to predict when breaks will happen, and carry out the repairs before the problems ever surface.
Ask me about repetitive DNA
This announcement is much bigger than just Postgres Integration, it also includes Xen virtualisation and Red package application support. This will surely make Solaris more attractive than RedHat now on x86-64
bæ8Ã0sÃOE?5r©oÂÃ?âz:ÃÃAÃ?ÃOEÂ6fXÃ?]Â
Actually, their premium 24x7 support is $360 per socket (not core). That's pretty goddam great for a big-boy operating system AND (now) database support.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Interesting. Could this be an indication of things to come?
Sun haven't been particularly enthusiastic about open source in the past. Most of the time they give the impressiosn of not really knowing what to do with it - like a kid with a really great new toy only they don't know how to use it. Take OO.o for example and the older funky licensing. They seemed to suffer from some weird love-hate dichotomy.
Sun used to be real big, well, I mean "bigger" - but really lost their way. Now we have Open Solaris, re-licensed OO.o, the funky new Niagra uber-processor (can't wait to see if^H^Hhow it works) and now what appears to be a very cool corporate offering of a OSS database - and a commitment to commit all modifications back to the project as well.
Did someone at Sun suffer from one of those wossnames...epithany thingies?
"...So I hung back and lurked. For 18 months. Can't beat a good old-fashioned lurking."
How will MySQL respond? I'd be sad to lose our investment over the last five years, but commercially the words "Oracle" or "Sun" just radiate comfort factor to less well informed customers.
Pining for the fjords
Who uses Solaris 10?
I assume you mean "uses it instead of Linux", what with this being Slashdot. How about people who've benchmarked it against Linux and found Solaris to scale better and more smoothly? Some of us like having beefy Sparc or Opteron SMP machines that perform predictably with Solaris, rather than the erratic behaviour we've seen with Linux on SMP Intel hardware. The 2.6.x Linux kernel has also been a serious disappointment in terms of reliability, a definite step back from 2.4.x.
Finally. Sun hasn't shipped a C compiler with its OS since SunOS 4.1.3 (circa 1990).
We moved from MySQL to PostgreSQL a few years ago, and couldn't be happier. The secret is to do it intelligently...
:= thread_count + 1; ON DELETE to THREADS, find the topic and thread_count := thread_count - 1; It's trivial when you get the hang of it, but then your system is lightning fast.
First, just do a straight port, get PostgreSQL running your MySQL data.
Buy a beefier server, because at this stage, PostgreSQL WILL be slower. For raw reading of simple databases (the old joke that MySQL isn't a real database isn't AS true anymore, but is in the ideas), MySQL is faster. PostgreSQL shines as you build more complicated system.
Second, use explain and start optimizing your system. MySQL develop tends to do series of queries, because the MySQL protocol is nearly "free." Doing 5 queries and doing the joins in the software in MySQL tends to be fast, but is REALLY slow in PostgreSQL. So start building more complicated queries using joins server side. At this stage, PostgreSQL catches up (or nearly so) with MySQL.
Third, learn PL/pgSQL. This lets you do a LOT of optimizations with triggers and functions. For example, if you need to look things up in 3 tables to get the Primary Keys, then query a third table, in MySQL you do 3 SELECTS, store the values in variables, then the final SELECT to get the data. In PostgreSQL that would be painfully slow (the connection costs kill you), so you do a massive join, which is okay if you have enough RAM and configure PostgreSQL to use it, but it sucks up memory. Then you build the PL/pgSQL function. This lets you do it the "old way" grabbing the data, keeping it in variables INSIDE the database, then doing the query. This is REALLY REALLY REALLY fast in PostgreSQL, keeps the RAM usage reasonable, etc. Sure you can throw 4-8 GBs at RAM cheaply, but when you start doing a bunch of really big JOINs and SORTs, you can't always get PostgreSQL to use it smartly.
Fourth, at triggers whereever possible. If you ever run a COUNT or other aggregate, re-think. For example, in a forum (trivial case, but fun), you may want to display the number of threads in a topic. Well, running a SELECT COUNT(*) on the threads JOIN topics will BE BALLS slow on PostgreSQL... HOWEVER, you instead do a trigger that keeps a count in the TOPIC called threads. You would do this in MySQL by having a second INSERT when you do a thread, but in PostgreSQL, you let the database handle it. ON INSERT to THREADS, find the topic and thread_count
Also, optimize your INSERTs. In areas where you currently check IF "is this already here" THEN UPDATE ELSE INSERT, you do that in stored Functions. function insert_or_update (values) that does an UPDATE and if it fails, INSERT, or otherwise does the logic server side.
Once you learn to do real database programming, even at the rudimentary level I described, PostgreSQL SCREAMS. If you are building web sites/web applications, they SCREAM. However, if you treat PostgreSQL the way most treat MySQL, as a data dump, you'll be miserable at the performance.
Final neat idea that we never implemented... but will one day. We were planning to use PL/php (there is a PL/perl) for a performance hack. For each major script that does a bunch of queries, even with optimizations, there is a final hack you COULD THEORETICALLY do... this is a hack, admittedly. Basically, instead of doing queries, define an associated array with all the data you want. In development, do a bunch of queries and put the data into the array, then process it. For optimization, move those queries to the server. Then you build the array in PL/php, serialize it, and return it as text. Now you call the PL/php function (SELECT get_FooPage_Info(page_identifier) that returns a text value, the serialized array. Now you have one database connection, it does ALL the work INSIDE the database process, and in PHP land, you just work off the array).
PostgreSQL is EXTREMELY powerful for areas where most people use