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).'"
First Apache, now Postgres?... What's next, will solaris understand cursor keys? Ship with BASH? What's the world comming to?
http://www.sun.com/software/solaris/news/111705.j
More about Postgres specifically:
http://www.sun.com/software/solaris/postgres.jsp
...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Ã?]Â
There is a blog from a Sun Engineer about databases, etc.. He talks about PostgreSQL, how to improve its performance, etc... You can find it here
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.
I don't think opensource databases are becoming any more of a threat than they were in the past. They really do cater to a different market. This is WHY you see SQL Express and the new Oracle license.
Here's the deal. The company where I'm the SysAdmin has 3 databases we support - DB2 (Linux and AIX), SQL Server (financial product decision made outside of our department without our consultation) and PostgreSQL.
DB2 runs our core database for our enterprise application. All databases were investigated at the onset of this project and DB2 came out on top. SQL Server is in house for a shitty financial package (Navision) and another legacy system. PostgreSQL is our data warehouse.
Because of some issues surrounding our DBA team and the fact that SysAdmins often have to cameo as DBAs in a quick pinch, I've come to learn quite a bit about DB2. It has its warts and bugs but it's 100 times more robust than PostgreSQL and 1000 times more robust than MySQL (which we use for a few self-managed databases here and there - intranet stuff/nagios).
We're currently migrating our data warehouse to a new hardware set and at the same time upgrading from 8.0.3 to 8.1 of PostgreSQL. This requires a restore of the database to migrate. This 80GB datawarehouse took the better part of a day to restore on a box that was 10 times faster than the original. Reading from different volumes on different controllers on our SAN on an x445 with 8 CPUs and 16GB of memory took 8 hours to restore!
This box used to run DB2 on Linux (we just migrated to AIX and a new SAN) and could restore a 100GB production database in 45 minutes.
The box wasn't being used. I/O wait was at 1% the entire time. Each of the 8 CPUs was 90% idle the entire time. Of course memory was maxed out because PostgreSQL uses the OS to cache for it but we weren't using any swap. This was using the native PostgreSQL compressed backup format.
Oddly enough for PostgreSQL, I had less insight into what the database was doing during that time than I would have with DB2.
In DB2 I can make memory changes on the fly - db cfg, dbm cfg and speed this process up. I can use db2mtrk to see what my memory is doing. I have things like bufferpools to allocate memory where it's really needed.
With postgresql, I can change a text file (which I love) but have to restart postgres for a lot of them to take effect. Some db2 changes require an instance restart as well but not many anymore.
Some of the problem lay with me and I'll admit that but some also lay with PostgreSQL.
The whole point is that DB2 and Oracle don't normally go after the same market as MySQL and PostgreSQL. Are there companies using those databases in place of DB2 or Oracle? Sure. And I'm sure they're very happy and have a nice humming system. Our warehouse runs wonderfully on PostgreSQL and there are no complaints but more often than not, the markets simply don't intersect.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
- DROP the java front ends for everything. We get gray waiting for loadtimes.
Sometimes I think Sun really didn't think out the Java GUI experience very well before implementing it. The reason you get those blank screens during load times is how swing threads. It uses the same thread for event handling as for screen redrawing. From a programming stand point, I'm sure it makes it much simplier to use their API's for simple GUI's. However, when you've got tools written for system administration that will almost definatly take some time to process an event, it makes for a bad end user experience. Java is a great language. However, their poor implementation of the GUI API's makes the end user experience bad. And ultimately people who use java programs think the whole language sucks because of a bad user experience with the GUI.
If an officer ever threatens to taze you, say you have a pacemaker.
Opening up? Things to come?
Sun has been one of the biggest commercial open source supporters for years now. Probably only surpassed by IBM and the Linux companies ( RedHat and Suse, Linux is their core business after all ).
Millions to buy StarOffice, millions to setup and run OO.org and OpenDocument development, marketing, promoting OpenDocument. Releasing packages like GridEngine, etc. http://www.sunsource.net/. Years of shipping and support opensource applications to companies that would never have used it otherwise.
Back when I was a network admin, we got a whole lot of GNU software in the system by first showing superiors that Sun endorsed those packages and actually provided solaris binaries.
Sun's main issue is PR, I suspect. When IBM does something good, it makes sure everyone knows. But that doesn't seem to be McNealy's style...
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Finally. Sun hasn't shipped a C compiler with its OS since SunOS 4.1.3 (circa 1990).
- ditch the forte crap and vendor lockin scheme
x .xml) on Tuesday. It's completely free to use unless you want support. They also ship lots of GNU tools included in Solaris (under /usr/sfw) in case you would rather use them.
) is up to five times faster than UltraSPARC-III and up to twice as fast as the initial UltraSPARC-IV. And the UltraSPARC T1 chip (code-name Niagara http://www.sun.com/processors/UltraSPARC-T1/index. xml) delivers incredible throughput (in my testing, often faster than a V40z with four Opteron 850 CPUs) while consuming much less power and generating much less heat than any other chip delivering anything close to the same performance and throughput.
Done. Sun released Studio 11 (http://www.sun.com/software/products/studio/inde
- ultrasparc performance is terrible. Address it.
Done. The UltraSPARC-IV+ chip (http://www.sun.com/processors/UltraSPARC-IVplus/
- get the X11 libraries and headers fixed - completely
Done. Solaris 10 (at least on X86) uses the Xorg implementation. The previous Xsun implementation is also available if you need it, though.
- Get ldap working without so many support applications
I can't say that I understand this one. Sun's Directory Server is the best performing and most scalable server available. It's very in-line with the standards so any LDAPv3-compliant application should work with it just fine. It is the preferred directory for use with most commercial LDAP-enabled applications.
- make your platform work better with OSS software (eg: gcc)
What else needs to be done in this area? Solaris 10 ships with a lot of OSS software, including GCC, and Sun makes a lot of additional OSS software available on the Companion CD (http://www.sun.com/software/solaris/freeware/). If that's not enough, you can use the SunFreeware (http://www.sunfreeware.com/) or Blastwave (http://www.blastwave.org/) collections to get what you need.
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