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).'"
See also the article about ZFS.
...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."
Well my question is an honest one. I have never ever seen a webhost with PostgreSQL, and the ones I know all say it's because it's hard to set it up in a multiuser environment. The support for user rights in the database is only part of the problem, you also need frontends and administration tools for both the webhost and the users. I've never seen any such solutions. And if they exist, why aren't webhosts using them?
I think it's shipped with bash since Solaris 7. It's definitely been there since Solaris 8 (/bin/bash).
If only Sun's PHBs had listened to the engineers, PostgreSQL could have been shipping with Solaris at least two years ago.
Sun's PHBs move in mysterious ways.
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 was wondering if it was possible to write stored procedure / functions in C# with postgreSQL. I know that with oracle and SQL server it's possible but for obvious reason ( $$, and I don't care about the SQL server express edition ), it's not really possible for me :P
I know it's a bit OT but I haven't really saw anything with google >_
"better yet, clean up the OS subsystem and make your platform work better with OSS software (eg: gcc)"
This one is funny. When Sun first did their 64-bit port of Solaris, the kernel guys used (drum roll please) gcc. Sun's C compiler wasn't up to speed, and it would take them too long to do it.
That was, what, 5-6 years ago? Clearly they missed an excellent opportunity to expand gcc then, but that would compete with their internal C compiler. Which ought to be killed off due to the stupid license manager which hinders every single compilation (so much so, that the Solaris O.S. buildmeisters have turned it off).
I swear, that License Manager has killed more good Sun products than anything else. Sun's dev tools for one. Teamware for another (Teamware was the first version of Bitkeeper; and both just rock). Too many PHB's at Sun these days it would seem. What a pity.
I think your comment may need clarification.
Clearly, Postgres works fine in multi-user installations. I am inferring that you probably mean that MySQL is easier to administer in the kind of multi-customer environments you have on boxes doing web hosting duty.
Of course, I have no idea whether this is true or not, since that's not the business I'm in. However, I suspect the historical popularity of MySQL as a rudimentary, low footprint data store for dynamic web sites means that there is more expertise in the web developer community. What you know is always simpler to admin. It may also mean that there are more tools, and more mature tools, for administering in web hosting environments.
I see both systems converging towards parity over time, in the core set of features that people find most useful in most every day applications. The kind of applications I do have very complex queries, and Postgres was a better choice for them because MySQL lacked support for complex queries -- up until recently. The only reason I didn't use Postgres much was that it wasn't on Windows, which my clients use. Up until recently. Postgres had spatial (GIS) data capabilities and MySQL didn't -- up until recently. The list goes on and on.
You can look at what people need in a database platform as a kind of pyramid, with widespread requirements at the bottom, and exotic or "enterprise" requirements at the top. Both platforms had somewhat incomplete foundations up to now, with a few second tier and third tier bits poking up here and there: object relational, spatial, replication etc. I'd say that as of 2005, the foundations of both products' pyramids are complete, and appear to be solid.
In 2006 I predict that people will start noticing this, and the products will establish a strong track record outside the kind of web and open source millieu and in the traditional bread and butter space for RDBMS vendors: IT. They won't displace SQL Server because of its integration with Microsoft's tool stack, but they'll make a dent. MySQL in particular will be integrated with many open source projects in the way SQL Server is a natural choice if you're working exclusively with Microsoft. If I were a betting man I'd lay money on MySQL and Postgres getting what peole in the software business is called "traction" by the end of next year.
If I were to put the relationship between MySQL and Postgres in familiar terms, I think they'll end up like Linux and BSD respectively. MySQL will have much broader popular appeal, and Postgres will appeal to a more select community with somewhat different values and culture.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Finally. Sun hasn't shipped a C compiler with its OS since SunOS 4.1.3 (circa 1990).
Because it does not have the latest and greatest in debug tools and Filesystems?
x .xml) as completely free (as in no cost, unless you want support) software. This includes their latest compilers, debugging utilities, performance anlaysis tools, and NetBeans-based IDE. I'd say that dbx compares pretty favorably with gdb, and they have achieved several performance world records with their compilers.
2 8_bit_storage_are_you). Its performance is already generally faster than UFS, and if you enable compression then it generally goes even faster due to the smaller amount of disk I/O. It is certainly a pretty advanced filesystem compared with EXT3/Reiser/XFS/JFS.
But I would say that it does have the latest and greatest in debug tools and Filesystems. With regard to debug tools, it has capabilities like DTrace, truss, kstat, pstack, plockstat, cpustat, etc. built into the OS. And on Tuesday, they somewhat quietly released Sun Studio 11 (http://www.sun.com/software/products/studio/inde
And with regard to filesystems, on Wednesday Sun released (http://www.opensolaris.org/os/community/zfs/) the complete source code to ZFS and Solaris Express build 27 which contains the first publicly-available version of ZFS in a form that anyone can download and play with. It offers quite a lot of features in areas like ensuring data integrity via strong checksums, and 128-bit addressing capability for virtually unlimited filesystem sizes (http://blogs.sun.com/roller/page/bonwick?entry=1
The announcement cites Postgres as Sun's RDBMS, bundled and supported. It also cites Solaris as Oracle's preferred (64bit) OS. Is Solaris now the best environment for developing relational apps on Postgres, then moving to Oracle for release versions? Will the Sun tech, support and Oracle partnership make the port from Postgres -> Oracle easy, even "automated"?
--
make install -not war
Sun working with BSD makes sense from a historical perspective as well. The original Sun OS was build on BSD, as Bill Joy, the technical founder was a big guy in the BSD world, and left to start Sun on BSD technology. Sun migrated from BSD to AT&T Unix after several releases.
As a result, their are probably elements of a BSD culture in Sun.
In addition, the GPL space makes it harder for a traditional software player to compete. The GPL makes sense for PURE hardware players (of which Sun is not, and in x86 space, it is REALLY tough to be a hardware player, only a few have done it, because Intel grabs the bulk of the profits leaving profits only for the most efficient manufacturers, and Dell dominates supply-chain management), as it elements the costs of software development... Dell wins in a GPL game, as costs come down from not paying for an OS, some of the savings get passed on to customers, some comes out as profits. Other players that don't dominate in supply chain issues aren't as well off.
In addition, the corporate GPL'd OS game is a services game. There is no real money in the OS license, so you have to sell support contracts. Now support contracts are high margin... IF YOU ARE REALLY GOOD. You have to be good enough that you don't have to do much on the support end... as each time support is used, your margins get eaten... it's an insurance model, and its a tough game to play.
The BSDs are more "corporate friendly," as the company can work with the BSD-core group to push up changes (otherwise you have to maintain forks, which is expensive, which doesn't really get you a competitive edge. So you have a financial incentive to push fixes upstream, but build add-ons or enhancements that you keep proprietary. In PostgreSQL and Apache, this works fine, as people develop these add-ons, they either release them to the world at large, in which case they are incorporated, or they keep them to themselves, and the core team has gotten a demo of what "can be done" for free... As Linux demonstrated, redoing known technology is SUBSTANTIALLY easier than building new technology.
Sun playing in BSD land makes a LOT of economic and cultural sense.
Alex
Actually, I'm insane enough to use it on my laptop with no other OS. OpenSolaris looks to be very promising, and it's a stable, nice system. I used to use Debian and FreeBSD, and so have found pkg-get to be a great replacement for apt-get and ports. And zones rock...I can run Tomcat and host webapps (my host doesn't support JSP or servlets) in the background without any visible effect.
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
Yes, no doubt you want it open. You are an engineer. Lets be honest. You are sitting there watching what Linux and StarOffice/OpenOffice is doing and loving what you see. While I am not part of Sun, I have dealt with Sun and have a few friends there (if you are really on the team, say howdy to semery/weasel).
But, this thread was describing Sun's PHBs. Your PHB's finally agreed to open this not because they found relgion, but because they want sales. To say otherwise would be disingenuous.
BTW, That is no different than the other companies that have done this before you; SGI, IBM, Dec, HP to name but a few.
I prefer the "u" in honour as it seems to be missing these days.
Actually that WAS done. The settings are really well defined for a datawarehouse environment.
Our biggest fact table has 48M rows if I'm not mistaken. It might actually be larger than that. As a side note about 1/3rd of that table gets updated every night as part of our warehouse load. Vacuums are a killer for us.
One thing I did read is that you could disable fsync for the restore process. We may just make that a normal documented task anyway.
On yet another note, since we're moving to new hardware, one thing we're doing (which is why we're restoring) is moving to 8.1. Greenplum has contributed some AMAZING changes back to postgres, not the least of which is the table partitioning. Try as you might, there are times when your optimizer will do a table scan no matter what. You simply can't outthink it. And most of the times, its been right. We ran some EXPLAINs on some of our reporting queries with table scans disabled and they WERE slower doing an index scan. With the table partitioning feature, we can break our tables out into smaller chunks without much extra effort.
Example:
Our loan account table could be broken out into loan_account with child tables of active, inactive, bankrupt, and whatever other WHERE criteria we want. At that point, we can actually have MUCH fewer rows to process if we just want bankrupt accounts. For DB2 people, the new PostgreSQL table partitioning is alot like an MQT. At least from the way I see it.
I'm also very happy that autovacuum made it into the mainline. DB2 has an autorunstats and autoreorg so this is something we're very interested in. The old autovacuum didn't really work as well.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
What he does is recompile Posgres to increase the default log block size. A commenter on his blog points out that he could have done this by changing a runtime parameter. In general, changing the block size used by the transaction log is something that should only be done by experts. I believe that Sun incents its employees to blog. In this case this posting is not necessarily a good sign of Sun's competence with Postgres.
Read Epic the first RPG novel.
No, Sun's PHBs had a very close relationship with Oracle. Either Ellison gave this the go ahead (he doesn't fear PostgreSQL) or Sun is firing a shot across Oracles bow.
As a developer considering starting a web company, I love what Sun has done with Open Solaris. Previously I was considering Linux on AMD64 servers, now Open Solaris on one of the new Opteron Sun Fire's is my top choice. With Dell's continuing refusal to use Opteron, it seems there is an enormous opportunity for Sun to build a competing x86-64 economy of scale and supply chain. You guys have such great offerings - Solaris, Linux, and (hate to say it, but at least it gives you diversity) Windows, plus the Opteron and your SPARC line, great engineers, and good support. Lots of opportunity for Sun right now...
Flying is easy, just throw yourself at the ground and miss. -Douglas Adams