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).'"
http://www.sun.com/software/solaris/news/111705.j
More about Postgres specifically:
http://www.sun.com/software/solaris/postgres.jsp
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
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.