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Ã?]Â
I think the general consensus on /. is that PostgreSQL is superior to MySQL
Flat-files and grep is superior to MySQL.
Who uses Solaris 10?
== Jez ==
Do you miss Firefox? Try Pale Moon.
no
I believe that Oracle is most often installed on Sun Solaris servers, so I am wondering whether Oracle should be worried by this announcement from Sun to offer extensive support for PostgreSQL. It seems that open source databases (Firebird, MySQL, PostgreSQL) are becoming greater threat to commercial ones like Oracle and DB2. Anyway, I think that PostgreSQL is great fit for Sun, because they will have relatively low development costs, but will nevertheless enable them to sell more hardware.
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."
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
You are missing the point. If articles had to represent some demographic then we'd all be reading articles about IE and Windows (to slightly paraphrase your comment). I don't use Solaris but I still enjoy the article.
It is exciting news for Postgres users. The prospect of Sun coming aboard and actually contributing is great. And 24x7 support will get more people aboard.
That sound you hear, to coin a phrase, is Sun, cutting off Red Hat's air supply.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
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?
What Larry Ellison thinks of this announcement...
There are no loopholes. It's either legal or it's not.
Both of my friends, who run CPanel cheap webhosting companies, offer PostgreSQL. For free. It's a little elephant icon right next to the MySQL icon in CPanel. I can assure you, they do exist. A quick check in the CPanel user manual shows a whole section devoted to PostgreSQL. As to how hard it is to set up from scratch - I couldn't say. But here's one way multiple users can use it extremely easily and quickly.
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
Vs pgAdminIII ?
Nice GUI admin tool. I like that much better than silly web applications.
beeing multiuser is just as easy in postgresql as mysql..
But if you for some unknown reason must have a web tool, there is phppgadmin
Um, kill -HUP forces postgres to reload config, it works for some (all?) configuration changes, and I didn't notice it being a real restart- clients don't get disconnected.
Fix me if I'm wrong, i didn't use this feature much. But it worked for me when I needed it.
--Coder
- 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.
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.
When they made the Postgres engine SQL compliant, they changed the name to PostgreSQL.
Finally. Sun hasn't shipped a C compiler with its OS since SunOS 4.1.3 (circa 1990).
Our shop is mostly Solaris (8) and RHEL with Oracle 9i. We're currently looking at upgrading our Solaris boxes to Solaris 10.
The problem? Oracle 9i is not supported on Solaris 10. It's supported on RHEL and earlier versions of Solaris.
So at the moment, it's not doable for us. But from the tinkering I've done with Solaris 10, it's actually pretty cool. I've got it running on an Ultra 10 under my desk and have been evaluating ot for a couple of months now. I'll tell you it's much lighter than previous Solaris versions (well, 7 on. 2.6 was pretty zippy in comparison later versions).
- 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.
Libraries. All 'Linux' tells you is where the system calls live (which number for which call). Red Hat Enterprise Linux tells you what libraries you can expect to find installed - i.e. what you can install without requiring additional dependencies. This is why some companies only support RHEL or SuSE (or whatever), rather than 'Linux'.
I am TheRaven on Soylent News
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
Yes, you think that's insecure, but the truth of the matter is that giving individual users their own MySQL username and password does not make it any less insecure. I am of the opinion that it's better not to lull people into a false sense of security: if they can see how sharp the blade is, they will be more careful when using a powerful tool.
Fact: it's trivial for any user with an account on a box to read any other user's files, even in their cgi-bin, since they must necessarily all be visible to the Apache daemon user {www-data on Debian systems}. And there's no way to obfuscate the database password: ultimately, the script has to send it to the server in the clear, so all you have to do is make a copy of the relevant file and replace a line that looks something like with That's bad enough in itself; but if the hosting company has decided to use the same password for MySQL and Linux login {and therefore POP3, FTP and maybe even shell access if they're on Gold} -- and there is at least one hosting company out there that are doing this {I had a reseller account with them once; I shan't name them} -- then Sir Hacksalot has the power to compromise more than just your database. One doesn't need to be terrifically "l33t" to find out which hosting company a competitor is using {as hard as it may be for you geeks who all have your own servers in your back bedrooms [and no hosting customers, except your own sisters' girly photo blogs, average 3 unique visitors per month, all bots] to believe this, there a lot of businesses who use hosting companies -- and more than a few who get their hosting done through cheapskate resellers}, get another account on the same box, and cause as much trouble as one can with a MySQL-based site.
The only way around this is for every user to run their own instance of the Apache server as themself, on a different non-privileged port; and to have a transparent proxy on port 80 that redirects requests to the appropriate port based on the host name. This way, users' files don't need to be readable to anyone save that user. Although it still would not be wise to use the same password for the two services, because a database password can still be exposed by careless use of chmod. And I wouldn't like to think how that is going to affect performance.
Je fume. Tu fumes. Nous fûmes!
Actually there is completely no point whatsoever in setting up MySQL as multiuser in a simple web hosting environment. You may as well just tell everyone to use "root" and no password.
Yes, you think that's insecure, but the truth of the matter is that giving individual users their own MySQL username and password does not make it any less insecure. I am of the opinion that it's better not to lull people into a false sense of security: if they can see how sharp the blade is, they will be more careful when using a powerful tool.
That's a really bad idea IMO.
Fact: it's trivial for any user with an account on a box to read any other user's files, even in their cgi-bin, since they must necessarily all be visible to the Apache daemon user {www-data on Debian systems}.
That's not a fact, but it is the sign the server hasn't been configured very well.
The only way around this is for every user to run their own instance of the Apache server as themself, on a different non-privileged port; and to have a transparent proxy on port 80 that redirects requests to the appropriate port based on the host name.
Shared web hosting platforms should really be using some implementation of per-customer compartmentalisation at the OS level if the users are allowed SSH access, or to run CGI's. Solaris 10 supports this natively, there are at least two separate native implementations of something very similar for Linux, Windows 2003 even supports this to some degree I gather (though not to quite the same extent) and then there are tools like VMWare.
Of course, running your MySQL server on an entirely separate hardware from your web server is also a Good Thing(TM), especially when someone manages to (most likely inadvertently) DoS your SQL server.
However, failing that, any web server used by multiple customers to run CGI's should at the very least be configured to use something like suexec, which has been a standard feature of Apache for about 8 years or so.
Using suexec (or gsexec, or cgwrap, or similar tool as appropriate for whatever web server your using) is precisely intended to prevent CGI's running as one user from accessing or modifying files (including other CGI's) that belong to another user.
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
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
I've used both firebird and postgresql for the last 7 years or so. My only complaint with firebird was that the Java JDBC driver was so much slower than the postgresql driver (this was a couple of years ago). I've been using PostgreSQL exclusively for the past 3 years or so. It isn't as easy to admin as Firebird, but also offers more functionality. For example, PostgreSQL lets you define procedures in nearly any language (python, perl, java, c, c++, etc). PostgreSQL's PL/SQL stored procedure language is (I hear) close to Oracles. Not that Oracles stored proc language is the end-all be-all, but consistency is nice.
I'm glad to see this. It seems MySQL gets way too much attention these days in the open source community. Not that it is a junky database server or anything, but I've been using Postgres for 4 years now and the system simply amazes me with every new release. It's power, ease of setup & maintenence and incredible stability (as far as I see it) is simply unmatched in the "free" database world. I would take it any day over an MSSQL Server. It's nice to see a company like Sun decide to include it in it's system and support it.
The PL's (like PL/PGSQL) are not for optimizations. They are for building triggers, etc.
Ok, there are a few areas where PostgreSQL performance sucks. Try doing an outer join between a moderately sized table (few million rows) and an empty table (zero rows). The result will be a nested loop join which will eat up your processor time for an insanely large time. The answer here is either to add a row to the empty table and vacuum analyze or rewrite your query to avoid the join against the empty table since this is meaningless anyway (this bad plan is a corner case in an optimization to prevent bad plans when tables grow rapidly between vacuum analyze routines).
A second area is that it is possible to create overly complex systems that are impossible to properly optimize. I have run into these cases before. Views of aggregates of views of aggregates are a great example. One should generally try to keep everything as simple as possible.
However.... Your suggestion that web server processing power is always cheaper than DB processing power is interesting but there are times when processing on the db server is cheaper than processing on the web server. For example:
1) If you can efficiently do joins and save the round trips, do them on the db side.
2) Data integrity is best enforced on the DB side if you have more than one app inserting or updating data in a DB. This is in addition to front-side checking and ensures that a bug in one app doesn't screw up data for another.
3) Look into PgPool and Slony-I for load balancing solutions that should enable you to add processing power for select statements at least as easily as you add processing power for web servers. This is best done when you have an app with lots of reads and a few writes (most web apps are this way). If you need something more complex, these technologies can be used to create more complex replication and load balancing solutions including multimaster replication systems in any architecture you can imagine with whatever conflict resolution algorythms you wish to use.
In short, it is not always true that adding processing power on the web server end is the least costly way to approach this.
LedgerSMB: Open source Accounting/ERP