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).'"

Comments

fp biotches!

[Anonymous Coward]

i rule!@#~ heh

Re:fp biotches!

[Anonymous Coward]

SCO uses MySQL.

Sun uses PostgreSQL.

Think about it, you fucking MySQL-maggots.

Solaris 10

[Eightyford]

Slightly off topic so mod me to hell, but... are there any custom distros of solaris worth downloading yet?

Let me be the first to say...

[Anonymous Coward]

W00t!!!

Trolltrain leaving at platform 9...

[Anonymous Coward]

Oh boy, I can't wait to read the spin the large contigent of shrieking anti-Sun trolls on Slashdot are going to put on this one. "They picked Postgres ahead of mySQL. OMG Sun is hating open source and trying to kill it as usual!"

Re:Trolltrain leaving at platform 9...

[Anonymous Coward]

I think the general consensus on /. is that PostgreSQL is superior to MySQL (technically as well as license-wise), so this would be a Good Thing.

Re:Trolltrain leaving at platform 9...

[Anonymous Coward]

I think the general consensus on /. is that PostgreSQL is superior to MySQL

Flat-files and grep is superior to MySQL.

Re:Trolltrain leaving at platform 9...

[the_thunderbird]

roflmao! Thats true, I think MySQL is a glorified version of MS Access with a TCP Server on the front... PostgreSQL on the other hand is the open-source oracle...

Progressive...

[Anonymous Coward]

First Apache, now Postgres?... What's next, will solaris understand cursor keys? Ship with BASH? What's the world comming to?

Re:Progressive...

[pedestrian crossing]

What's next, will solaris understand cursor keys? Ship with BASH? What's the world comming to?

Solaris has shipped with bash for quite a while now...

Re:Progressive...

[Anonymous Coward]

No, it's Postgressive.

Re:Progressive...

[Anonymous Coward]

But has it offered you the ability to pay thousands of dollars per year to have full 24/7-support via a expensive hotline and make you feel professional by shelling out money for useless "service"?

I think not, Siree!

Re:Progressive...

[$RANDOMLUSER]

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.

Re:Progressive...

[$RANDOMLUSER]

Damn, blew the link - should've (should have, not should of) previewed.

Re:Progressive...

[mabinogi]

hmm...they must've (must have - that bothers me too ;) ) changed their pricing. Part of the reason we switched to Dell years ago, was that for the price of the support on our Sun machine, we could buy a whole new Dell machine every year....

Besides - With Sun we were paying all that money and never had to make use of it - with Dell, you regularly get to feel like you're getting something for your support money ;)

Re:Progressive...

[Anonymous Coward]

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.

Re:Progressive...

[WindBourne]

Sun's PHBs move in mysterious ways.

Actually, they don't. What is going on, is a inside fight.

There is a group there that fears MS (rightly so). They think that dealing with MS is dealing with the devil. They really want to crush them at all costs. This group pushes Sun towards the OSS path. The group is also responsible for the approach with OpenOffice as well as Java. Problem is, that MS won the desktop sometime ago, and is entrenched. Taking it back is a very difficult thing to do. As to server space, They do not see MS is taking from them (probably right). That group is helping linux.

The other group sees Linux taking from them (rightly so). Linux has been eating up server space. They are taking away from Solaris. This group did open solaris as a way of winning very lucrative support contracts and hopefully to sell hardware. One of the keys here is to try and make Solaris more like Linux. So they are trying to adopt a number of OSS and claim that they deserve the OSS worlds support. What is interesting is that they are starting to support BSD (I am not sure if they are looking to take it over or as support against Linux; more like a long-term trojan horse).

So what does it mean? That Sun is like any other large firm. There are multiple fractions playing games in house and McNeally lets it go.

Re:Progressive...

[Anonymous Coward]

Solaris has had bash since at least Sol 9. /bin/bash

Re:Progressive...

[donuthole]

I'm sorry, I don't often reply on Slashdot, but I have to reply this because it's so pointedly wrong. Sun didn't open source solaris to win support contracts and sell hardware. They open sourced it to generate a community around it and to increase developer and academic interest. The engineers working on Solaris have been wanting to open source Solaris for ages to try and increase adoption. I'm on the OpenSolaris engineering team, so I'm pretty certain I know what's going on around me here.

Re:Progressive...

[WindBourne]

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.

Re:Progressive...

[donuthole]

Ultimately, yes - anyone who works for a company wants the company to make money. Whether it's Sun, Google, Microsoft, or the Roman Catholic Church.

You can't honestly work for a company and not want to increase sales.

It's how you go about increasing those sales that matter though. You can do it the right way: by increasing adoption with a competitive product.

But that wasn't what you said. You said there is a faction within Sun who opened solaris as a way to win lucrative support contracts and sell hardware. through many indirect ways... yes, you could argue that... since OpenSolaris adoption naturally might lead to commercial Solaris adoption, which would in turn lead to support contracts. But you paint it as though Sun open-sourced with the primary objective to be to win lucrative support contracts.

Honestly, the companies and people who buy those lucrative support contracts probably don't care that Solaris is open source (unless they're a gov't agency w/ an open source mandate). They would have bought the support contract anyway. OpenSolaris's prime objective is to increase adoption, and we're not targeting the Bank of Americas, Googles, and GE's of the world with OpenSolaris. We're targeting developers and students which Linux took away (as you pointed out, correctly).

Re:Progressive...

[ahdeoz]

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.

Re:Progressive...

[aztracker1]

I think they are doing a very good job of positioning themselves, their tools, hardware, and solaris against other offerings.. I beleive that this decision to go with Postgres probably has more to do with pl-Java than anything else, to better position itself against the managed/.Net procedural additions to Microsoft's SQL 2005.

Their desktop previews are pretty cool, and if they can beat Vista to market by 6 months, with the direction they are going, they could really regain some ground in business deployments. I've been favoring Novell's directions a bit more, but Sun seems to be doing a better job of it.

Re:Progressive...

[fbg111]

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...

Re:Progressive...

[andreyw]

It'd be nice if SOlaris understood the concept of *virtual consoles*, or been able to switch between X and a VT.

I didn't know OpenBSD had VC support. Turns out the hot-key combo was different - it's Ctrl-Alt-F#.

Re:Progressive...

[Anonymous Coward]

By "world-wide 24x7 support", we really mean "someone will always be there to answer your phone, but unless it's 8-5 Pacific Standard Time, you probably won't reach anyone that has a clue about the product".

Re:Progressive...

[Anonymous Coward]

Only newbs run bash in Solaris.

$ /usr/bin/ksh
$ set -o vi

Can you handle the power??

Re:Progressive...

[mikefe]

Actually, their premium 24x7 support is $360 per socket (not core).

Whew, you had me worried for a minute. At least that's only per minute and not per core.

ZFS Source Code

[Anonymous Coward]

See also the article about ZFS.

More links

[ChrisRijk]

A kinda generic news page about the Postgres announcement:
http://www.sun.com/software/solaris/news/111705.js p

More about Postgres specifically:
http://www.sun.com/software/solaris/postgres.jsp

• Sun is working with the PostgreSQL community.
• Postgres for Solaris will be included with every copy of Solaris 10, with full support available from Sun
• Support for Solaris 10 and Postgres will be less expensive than support for Postgres and standard commercial Linux offerings.
• Many of many customers enterprise database needs can now be served with free and open source databases.
• The open source database is only one component of Sun's open source strategy that aims to provide customers with breakthrough new technologies based on open standards.
• Sun will provide feature-specific optimizations, such as DTrace providers, service manifests and Solaris Containers capabilities, enabling Postgres for Solaris to take advantage of key Solaris 10 technologies.
• Enhancements in Postgres for Solaris will be contributed to the PostgreSQL open source community.

It can see into the future

[gringer]

...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.

Re:It can see into the future

[quarkscat]

You might call "Predictive Self-Healing" an "oracle".

Who knew that the HAL-9000 ("2001" reference) would actually be made by SUN Microsystems?

SUN has made some great moves (Opteron-based workstations and servers), great new UltraSparc (T1) processors, a rock solid OS that they have open sourced (Solaris 10), and now their alignment with PostgresSQL. I am truly impressed. It looks like they have made all the right moves. Perhaps they have used SGI (Silicon Graphics) as an object lesson as to "what NOT to do", since SGI has been de-listed and is "circling the drain".

Re:It can see into the future

[assantisz]

They don't really predict anything but they can give a good guess when a CPU or memory starts failing and should be replaced before it fails completely. S.M.A.R.T. in disk drives, for example, is an example for predicitive abilities. The self-healing part (and that's what's already in Solaris 10; the predictive part is not quite here, yet) just makes sure that failing parts are isolated (e.g. take a processor board off-line so it can be swapped out) or services are restarted automatically.

More info about this on BigAdmin.

Re:It can see into the future

[drinkypoo]

Sun has also made some boneheaded moves. Can't shake the devil's hand and say you're only kidding. ("They Might Be Giants" reference.)

Fucking great.

[Spazntwich]

Yeah, moderate me off topic, troll, flaimbait, or otherwise, but considering how many worthwhile articles get ignored and how many worthless ones get duped, how does shit like this make it onto the front page?

Nobody gives a flying fuck about Sun's latest announcement of compatibility with their dated and obsolete software. Nobody gives a shit about some obscure product recently reviewed and submitted by the same person. This article is a prime example of why slashdot has sucked hairy electronic cock lately, and it needs to stop.

To be completely honest, I don't even know why I'm punching my karma in the throat like this. It's only going to fall on deaf ears anyway.

Re:Fucking great.

[Anonymous Coward]

Then filter Sun topics you fucking baby.

Re:Fucking great.

[chrstphrb]

"It's only going to fall on deaf ears anyway" Deaf ears? Please provide coordinates so we can point the VLA at your planet and hear more...

Re:Fucking great.

[Pieroxy]

Nobody gives a shit about some obscure product recently reviewed
Maybe the few millions users of solaris do actually care?

Tip: What you don't care about may have some interest for someone else.

In other words: You are not the center of the world (even though it looks like it from you narrow point of view).

Re:Fucking great.

[Spazntwich]

While your comment is cute in an esoteric sort of fashion, considering the fact that even the vast majority of slashdot visitors are IE users, I doubt Solaris supporting a new type of SQL qualifies as front page news.

I'm not the center of the world. Neither are you. However, I think we can both agree that the number of /. visitors that both use Solaris and give two shits about support for PostgreSQL are even farther from it than either of us.

Re:Fucking great.

[hedleyroos]

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.

Re:Fucking great.

[Spazntwich]

If this story qualifies as exciting for anyone, they should probably give serious thought to killing themselves.

Re:Fucking great.

[v01d]

I think you could extend that argument to anyone who finds /. exciting.

Re:Fucking great.

[Anonymous Coward]

To be completely honest, I don't even know why I'm punching my karma in the throat like this.

The evidence suggests that you are stupid.

Anyway, thank you for fulfilling my prediction.

Re:Fucking great.

[joey_knisch]

I think what you have run into is the slashdot nerd-ego. There are a ton of /.rs that think they are gods gift to technology. They like to hear themselves talk about "nerdy" things so they get these articles about software they will never touch and pretend to read it just hard enough so they can spout off about it to a cube neighbor.

I know at least one person will tell me about this article today and:

1) they have never set up postgresql.
2) they have never set up solaris.
3) they sure as hell havn't set up postgresql on solaris.

perhaps /. editors should have a nice article about firefox (since they released v 1.5rc3)
or google (since a link "Try searching for test on Google Book Search") is now in my results
or any number of other tech related happenings.

Re:Fucking great.

[liliafan]

Actually I read /. everyday and Solaris is my favourite operating system, I have used Sybase, Mysql on Solaris 8 and 9, I have used Postgresql many times in linux and I am now looking forward to installing postgresql on my solaris boxes. But beyond that what is important about this article isn't so much that it doesn't relate directly to /. users as perhaps many of them don't use Solaris or Postgresql, but how it relates to Sun moving even further into the world of open source, they are now directly offering support and at low cost for an opensource database, this is hugely important because it gives a good indication that Sun is really truely commiting to OSS, rather than the lip service they have offered in the past.

Re:Fucking great.

[joey_knisch]

It wasn't relevant to my previous point but I run Solaris on one of my boxes and postgresql on another. This story is relevant to me. I was just venting about my coworkers who will tell me about shit that I know more about after they have read /. As to your Sun moving further point, there are better indications in the news like Sun releasing Sun Studio 11 for Free. I haven't used it yet and I know it's not OSS yet but I bet it beats the pants off of eclipse + c++ plugin, kdevelop, or anjuta. This is a far better gift to open source than postgresql support, yet it probably won't receive a bit of news on /. I would submit it but that always seems useless. I don't think my article submissions ever have enough mistakes to qualify.

PostgreSQL is good

[Daath]

Ok, a bit offtopic, but this interests me. I worked a little bit with PostgreSQL in the past and remember thinking it was pretty good - Recently in a project we used Firebird (formerly known as Interbase), and I really got to like it.
Can anyone tell me the pros and cons of postgresql vs. firebird?

Re:PostgreSQL is good

[Anonymous Coward]

no

Re:PostgreSQL is good

[Anonymous Coward]

lol

Re:PostgreSQL is good

[gnuLNX]

LOL! not sure why that made me laugh so damned hard.

Re:PostgreSQL is good

[Kunta Kinte]

Can anyone tell me the pros and cons of postgresql vs. firebird?

One advantage to firebird is that it has an embedded version whilst PostgreSQL doesn't.

Currently I use SQLite but I am thinking of moving to firebird embedded for its extra functionality.

Re:PostgreSQL is good

[Anonymous Coward]

Agreed. It would be a killer feature for Postgres. An embedded postgres would allow developers to include an extremely capable RDBMS that could easily be distributed as a library linked with an app... but which would allow easy migration to a full server-style postgres installation -- especially considering the BSD license used for Postgres. No fucking around with complicated installs and setting up... just bang... it works on the users system, but allows for future growth.

Just look at the usage SQLite gets... Microsoft does something similar with MSDE (which is just a mildly crippled SQL Server).

Re:PostgreSQL is good

[Anonymous Coward]

Can anyone tell me the pros and cons of postgresql vs. firebird?

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.

Much bigger than just Postgres

[axonis]

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

Re:Much bigger than just Postgres

[axonis]

Sorry "RedHat package application support" - doh !

Re:Much bigger than just Postgres

[panic_smooth]

...providing world-wide 24x7 support for customers who wish to develop and deploy open source database solutions into their enterprise environments

will they be providing the database hardware from their completely unused pay-for-use sun grid facility?

Re:Much bigger than just Postgres

[The Nine]

Red package application support

I knew those damn Sun bastards had turned communist when they released the Solaris source code!

Re:Much bigger than just Postgres

[Anonymous Coward]

that's outdated. someone bought 1 million hours of their grid already.

Re:Much bigger than just Postgres

[Anonymous Coward]

This will surely make Solaris more attractive than RedHat now on x86-64

As long as you're using supported hardware, don't want the full sourcecode and don't mind being tied into Sun's silly license? In other words, it still makes more sense to be running linux. Sun should really ditch their OS, it's a waste of their resources and every body elses time.

Re:Much bigger than just Postgres

[WindBourne]

Yeah, but it does not count if that is Sun itself.

Re:Much bigger than just Postgres

[Gilmoure]

What about colour? Or Cheque?

Re:Much bigger than just Postgres

[Anonymous Coward]

The "u" is actually "you" from honor (play on words/char).
Are you missing from color or check?

Yeah, but...

[Nuffsaid]

This sounds good, but you can't say that Sun's behaviour recently has been spotless...

Also...

[Anonymous Coward]

This 24x7 support thing scares me. Think of all the sleepless nights!

Why MySQL and not PostgreSQL?

[HvitRavn]

From what I've heard from my webhosts, MySQL is easy to get up and running in a multiuser environment, whereas PostgreSQL is not quite that easy. I have not explored the multiuser capabilities of PostgreSQL myself, but I guess it may as well have to do with the available admin tools (phpMyAdmin vs ???).

Re:Why MySQL and not PostgreSQL?

[sauge]

Someone needs to do more research. I have found PostgreSQL to be just as easy to start up as MySQL. There are PHP and GUI administration tools available also.

Re:Why MySQL and not PostgreSQL?

[Anonymous Coward]

And what would be the problem serving Postgres in a multi-user enviroment? Doesn't it also have users with database permissions? I'll say more, you can have table level permissions in PGSQL and different schemas within a database with varying permissions. There's a lot to be said about MySQL, but not that it is capable of more than PGSQL.

Re:Why MySQL and not PostgreSQL?

[HvitRavn]

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?

Re:Why MySQL and not PostgreSQL?

[HvitRavn]

Please see my above comment, #14061391.

Re:Why MySQL and not PostgreSQL?

[kuiken]

http://www.postgresql.org/support/professional_hos ting

A list of webhosts that support pgsql.

Re:Why MySQL and not PostgreSQL?

[Skye16]

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.

Re:Why MySQL and not PostgreSQL?

[Anonymous Coward]

Because Solaris is a real Operating System targeted at professionals. The people who will be installing and configuring PostgreSQL on Solaris 10 will have problems with the configuration. Those who are used to playing Sysadmin on their Gentoy box running MySQL will obviously find the idea of configuring PostgreSQL hard.

Re:Why MySQL and not PostgreSQL?

[ratatask]

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

Re:Why MySQL and not PostgreSQL?

[moro_666]

after some point, the administration of postgresql is imho much clearer than the mysql version ... and as for setting it up, if you can read the manual, you should be fine :)

but i don't think you should choose a database by how hard it is to set up (people that 5 years ago tried to install oracle on redhat , like me, know what means a hard to set up database), instead you should choose the database by it's capabilities for your applications. if you need simple fast selects, go mysql, if you need very deep recursive selects and stored functions, go for postgresql or any other real database.

mysql is picking up pretty fast lately, but it's still behind. if they have a stable version with optimized subqueries and heavily tested stored procedures, it's worth a look.

Re:Why MySQL and not PostgreSQL?

[DrSkwid]

your webhosts are losers, time to move on

Re:Why MySQL and not PostgreSQL?

[hey!]

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.

Re:Why MySQL and not PostgreSQL?

[ajs318]

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.

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

$dbh = DBI->connect("DBI:mysql:database=stuff;host=localh ost",$db_user, $db_passwd);

with

print "'$db_user' '$db_passwd'\n";

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.

Re:Why MySQL and not PostgreSQL?

[Anonymous Coward]

Perhaps because MySQL is already included in Solaris?

$ pkginfo | grep MySQL
system SUNWmysqlr mysql - MySQL Database Management System (root component)
system SUNWmysqlt mysql - MySQL Database Management System (test component)
system SUNWmysqlu mysql - MySQL Database Management System (usr component)

Re:Why MySQL and not PostgreSQL?

[@madeus]

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.

Re:Why MySQL and not PostgreSQL?

[Just Some Guy]

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}.

Why would you do that? Instead, create a new secondary group for each customer, and put only them and Apache into that group. chgrp all of their web files to that group. Give said files mode 640. Voila: Apache can read (but not write) all of their web data, but nothing in their home directory. No other customers will be in that group, so they don't get access.

The scenario you described would be trivially crackable, but who in their right mind would run a setup like that?

Re:Why MySQL and not PostgreSQL?

[Anonymous Coward]

That is one reason I like Windows hosting.

On IIS 6.0, you can run each application pool under the user's account. Then you setup NTFS permissions so that only the user's account has access. No other account can then get access, no matter what credentials are used (NETWORK SERVICE, SYSTEM, etc).

For connecting to the MSSQL database, Integrated Security is used, so that only the web application pool user (the user's account) has access to the database.

No passwords are ever in clear text, and user's files and databases are completely isolated.

Cue the W1nd0z posts, but with Windows 2003 and IIS 6.0, sites are now just as secure as a Linux and Apache setup. The NT4.0/IIS4.0 days are gone. Microsoft finally has a good server platform.

Re:Why MySQL and not PostgreSQL?

[DrSkwid]

suexec

each virtual host is assigned it's own user

for a while there it sounded like you knew what you were talking about

Re:Why MySQL and not PostgreSQL?

[DrSkwid]

> but with Windows 2003 and IIS 6.0, sites are now just as secure as a Linux and Apache setup.

that isn't saying much, privilege escalation problems appear regularly for both systems

root/administrator is a design fault, no amount of patching will ever get round that one

Re:Why MySQL and not PostgreSQL?

[ajs318]

The problem with that method you describe -- separate groups per user with www-data as a member of each one -- is that each user's scripts, running as the www-data user -- which can read files from any user's web space -- will still be able to read any other user's files.

In other words, it won't work.

Re:Why MySQL and not PostgreSQL?

[ajs318]

Yeah, but not having root / administrator at all would be worse.

Any "normal" user account which is allowed to do anything only root should be doing, is potentially as big a security risk as root. Even enabling root access in hardware isn't ideal, since it will create problems around servers in co-lo.

It's a double edged sword that cuts both ways.

Re:Why MySQL and not PostgreSQL?

[ajs318]

Now I've seen the documentation, that does actually look as though it would do the business.

It does say something that it's turned off by default, though ..... looks like it might be really easy to mess up and end up with a system that either won't execute CGI scripts at all, or isn't as well-protected as you think it might be.

But I Postgress...

[dotslashdot]

Better Postgress than never. Stay tuned for the SQL.

An honest question.

[jez9999]

Who uses Solaris 10?

Re:An honest question.

[brennz]

The #opensolaris channel on irc.freenode.net has 116 people in it right now (6 AM EST). While the majority are AFK it shows there are people interested in it.

My past beef with Sun was the shoddy x86 support (remember Solaris 8 x86 that aptly deserved the moniker slowaris?) and negative approach to Linux. Since their recent adoption of AMD X86-64, less doublespeak on Linux, and OSS-ing of Solaris though, I'm willing to take another look.

Maybe they are starting to wake up and smell the coffee......java perhaps? :)

Re:An honest question.

[v01d]

Who uses Solaris 10?

People trying to do stuff?

Re:An honest question.

[LizardKing]

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.

Re:An honest question.

[Tony Hoyle]

From a commercial point of view Solaris 10 isn't in the roadmap yet - looking at our customers it's evenly divided between solaris 8 and 9 (couple of solaris 6) and zero solaris 10.

The shift will probably start happing in the next year or so... then we'll have to buy another sparc box to support it (any excuse...)

Re:An honest question.

[suezz]

" less doublespeak on Linux"

I don't find that to be true. I took a bootcamp on solaris ten a couple of weeks ago and he started with quoting linus and comparing the quote to bill's famous 64k nobody will ever need it.

then they go ahead and tell us what they learned from open source.

sun is just trying to survive and they will do ANYTHING to survive. guess I can't blame them cause I would do the same.

but I wish they would just quit slamming linux and stop the double speak.

Re:An honest question.

[v01d]

I've seen relatively few Solaris 10 systems in production, but most new development work on Solaris is for 10. So far 10 looks like the most actively planned for version of Solaris I can remember.

Re:An honest question.

[WindBourne]

How about people who've benchmarked it against Linux and found Solaris to scale better and more smoothly?

interesting. Do you remember when Sun was going to release OpenSolaris and they held back. The reason they held back was that internal benchmarking found that Linux 2.6 was killing everything that they had. They had to redesign and recode their networking (according to a friend of mine who did this, they borrowed heavily from the OSS world for ideas; but he swears it will beat them for a while). In addition, the reason to hold of their filesystem was that they found out that it was losing BIG time. It is in a massive rewrite. It turned out that Linux scaled and ran quite well.

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.

Odd. I have not seen any of this erratic behaviour. In fact, I have 5 machines at my house and 5 others in a business that run great(all on 2.6).

The 2.6.x Linux kernel has also been a serious disappointment in terms of reliability, a definite step back from 2.4.x.

Actually it hasn't been. From what I have ran, it has been flawless. In actuallity, I know that there are rough edges, but not in the core. And the rough edges are places that Solaris does not do.

Re:An honest question.

[M1FCJ]

I guess you are leaning towards Fujutsu boxes, aren't you? Sparc based Fujitsus were quite impressive.

Re:An honest question.

[C_Kode]

I've found that Solaris 10 has so many problems that I wouldn't dream of using it even in a box at my house that I test on. It's proven to be trash and not worth the ascii text it's written in.

Now, we are in the same boat. I made several claims that one OS sucks yet I didn't list any references to support my claim.

That force me to discount your entire statment and all creditability.

Solaris 10 is a very nice OS, but my Oracle 10g RAC runs quite nicely on RHEL3 x86-64. (SMP Opterons (DBs) and SMP Xeon (app servers)) We migrated away from Sun for several reasons. Solaris 10 fixed many of them, but today it's a little to late and we arn't willing to fix whats not broke. I mean why add cost and work if everything is working as it should?

I would love to hear where your "serious disappointment in terms of reliability" stems from. I can tell you where my disappointment in Solaris 7-8-9 stem from but I see no reason to bash Solaris. I found Linux superior in almost every way for what we use it for in a weighted comparison. (YMMV) It's why we use it now and will continue to until we find enough reason to switch again. (Obviously once it's time to upgrade again)

Anyway, if you make a claim support your claim with references otherwise you shoot your creditability in the foot.

Re:An honest question.

[assantisz]

You are right. Most Solaris admins don't jump to the next best release when it comes out. It usually takes a long time to go from one version to the next. Many even skip one. I, for example, am running Solaris 8 on all my production boxes. We just started planning for a migration to Solaris 10 while skipping 9. The move from 2.6 to 8 took a couple of years and my guess is that the move from 8 to 10 will take that long again.

If it wasn't for DTrace, Zones, and ZFS I would stick with Solaris 8 for even longer.

Re:An honest question.

[twiddlingbits]

Doublespeak? Sun SUPPORTS Linux on it's hardware, but it does not PROMOTE Linux. How is that doublespeak? If someone wants Linux instead of Solaris they are supported. But for my $$$, I would run OpenSolaris which is rock steady if I was low budget, or Solaris 10 if I wanted all the features like Dtrace, etc. and could afford the licenses. Solaris 10 is a very solid UNIX OS with 20 years of history behind it, and it runs any other Solaris binaries for the same platform. You can't say that about Linux. Last I looked something that ran on RHEL wasn't going to work on SUSE or other distros.

Re:An honest question.

[twiddlingbits]

Stick with an OS (Solaris 8) that is approaching EOL? That might be OK from a sysadmin perspective but not from a business perspective. Plus, Solaris 10 is going to support your Solaris 8 apps and most of the scripts even. It is also a lot faster, more secure as well as what you mentioned. The BIG issue is that a lot of small-to-medium ISVs have not "qualifed" thier apps with Solaris 10 and will certify they work which is something that concerns a lot of IT Managers. Expect the pace of certs to increase.

Re:An honest question.

[assantisz]

You might want to check out the support matrix. Solaris 7 is still being supported for more than two years and no dates have been announced for Solaris 8 and up.

I am not saying that I am going to run Solaris 8 forever. I am just saying that I am speeding up the transition to Solaris 10 only because of the features it offers. They make my life as sysadmin much easier.

Re:An honest question.

[whayworth]

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.

Re:An honest question.

[chris_mahan]

Isn't Solaris 10 free-as-in-beer as well?

http://www.sun.com/software/solaris/get.jsp

Yes you can use that in production systems, and yes you have to tell them how many installs you're gonna do. But if you don't need support, you don't have to pay them a penny.

It's just not opensource.

Re:An honest question.

[twiddlingbits]

It might not be the best strategy to force moves to Solaris 10 but it is coming. Newer Sun H/W (i.e. Niagra, Galaxy) will support only Solaris 10 so as your Sun equipment is EOLed that too will force you to move or go unsupported or make a lifetime buy and support yourself.

Re:An honest question.

[twiddlingbits]

That's true of a lot of Sun software. However, you WILL need support if you run an Data Center of any size. Solaris 10 has a lot of new things, and IIRC if you don't buy support you don't get tech help, patches, upgrades, etc. Of course you can get those in other ways...

Re:An honest question.

[chris_mahan]

True, takes more work to keep your system going, and if you're a real business making real money you'd better pay for support.

But I use Debian for all my servers.

Re:An honest question.

[Homology]

In addition, the reason to hold of their filesystem was that they found out that it was losing BIG time. It is in a massive rewrite. It turned out that Linux scaled and ran quite well.

Massive rewrite in a filesystem? Bugs in a filesystem is scary since just about everything depends on a filesystem actually working. I know Linux like to have their "filesystem of the week", but others prefer relability and stability....

Re:An honest question.

[Anonymous Coward]

zfs was suppose to be released with opensolaris. It was halted at the last minute due to the benchmark issues. For the last 6 months, it has been undergoing a rewrite and stabilization. And yes, commercial companies do this ALL the time.

Re:An honest question.

[whayworth]

Funny you should say that, because the GNU foundation has credited the CDDL, which open-source Solaris is licensed under, with being a free (but GPL-incompatible) software license.

http://www.gnu.org/licenses/license-list.html#GPLI ncompatibleLicenses

Re:An honest question.

[Anonymous Coward]

UFS has been the filesystem that Solaris (and SunOS before it) used since the beginning and has not had "massive rewrites." The addition of features like direct I/O allowed database performance better than 90% of that on raw disk and metadata logging has helped stability and performance in other applications.

Note that UFS, like most Unix filesystems other than ext2fs, has traditionally written metadata synchronously to prevent filesystem corruption. Before logging was added, this made it much slower on simplistic "create gobs of tiny files" microbenchmarks. On the other hand, if you crashed your system in the middle of a test or compile, you didn't lose parts of your directory trees.

I think the original poster is trying to spread FUD about current Solaris stability by making unsubstantiated comments about the upcoming ZFS filesystem. By the way, ZFS also incorporates a lot of functionality typically found in volume management systems.

Re:An honest question.

[Anonymous Coward]

The rewrite of the network IP stack for Solaris 10 started so long ago (do you understand how long something major like this takes to do in a stable and backward compatible manner?) that it's hard to believe that the relatively recent release of the Linux 2.6 kernel had any bearing upon Sun's decision to do it. Who is your friend that's telling you this stuff?

The engineers at Sun I've talked to have always said that delays in releasing parts of the source code have been due to the time it takes their legal staff to vet code for copyright issues and get/buy permission for release from third parties when necessary, not due to engineering concerns. Sun pays for all of this and does not want to get sued just because you'd like them to hurry up. Any parts of the code not available in source form are provided in object or executable form, so it's not like any performance issues would be hidden.

Re:An honest question.

[chris_mahan]

Solaris 10 is not released under the CDDL. OpenSolaris is.

Re:An honest question.

[AFCArchvile]

Anyway, if you make a claim support your claim with references otherwise you shoot your creditability in the foot.

Look who's talking. I didn't see you give a single reference to support your claims.

Re:An honest question.

[whayworth]

True, but there are already bootable OpenSolaris distros, and you have a choice: OpenSolaris or Solaris (Sun-supported).

Re:An honest question.

[Anonymous Coward]

quote from grandparent post: "Now, we are in the same boat. I made several claims that one OS sucks yet I didn't list any references to support my claim."

You don't read much, do you?

Re:An honest question.

[Z4rd0Z]

Wow. You have a whole ten machines and found it to be "flawless". Meanwhile, there are people who actually use computers for Real Work who might have more than the anecdotal evidence you seem so fond of sprinkling around Slashdot. I have nothing against Linux, mind you. I'm just tired of your zealous trolling, and not enough people have stood up to put you in your place, so I'm volunteering for the job.

Re:An honest question.

[mikefe]

[...]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'd like more details on your workload. What are you running, how much memory do you have and what kernel versions from what distro? Did you try a NUMA enabled kernel on the opteron systems? What simptoms did you see?

Re:An honest question.

[WindBourne]

I am not quite sure why you think that I am trolling. I was responding to the OP who stated that linux was crap, and I was stating a fact, while he was stating an opinion with nothing to back it up. As to volunteering for whatever, looking through your postings, I would say that you already troll enough.

Re:An honest question.

[suezz]

It promotes it but at the same time slams linus when it can. All I am doing is reporting what the guy said at boot camp.

They need to stop trying tear down linux and start working with it. I think the teacher was way out of line comparing linus's quote to billy's 64k quote. gates isn't even in the same class of person as linus and they should never be grouped together.

solaris has it's place in the data center - it is great for high end stuff like their 6800's and above. but that is about it and sun just needs to realize that and try to help linux overtake microsoft for the desktop.

I think sun for some reason or another has their feeling hurt from linux and are just trying to match it on everything it does. Solaris just can't do that. I administer sun boxes for a living too and I think it is great for the 6800's and above. but linux is truely cross platform and I can have the same interface running on sparc, x86, amd64, itanium, pppc, and probably a few others that I have left out. solaris just can't match that and probably really shouldn't try.

Goodbye to Oracle ?

[camiel]

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.

Re:Goodbye to Oracle ?

[tweek]

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.

Re:Goodbye to Oracle ?

[Anonymous Coward]

Navision? Jesus. I feel your pain.

Re:Goodbye to Oracle ?

[Anonymous Coward]

different markets entirely. Oracle probably (a) doesn't care, and (b) is somewhat pleased. People will start off using PostgreSQL, and as their business scales up they'll find they need more, and walla Oracle's waiting there (until they scale up, Oracle's not interested either, by definition, they won't have enough money for Oracle until they do :-).

Re:Goodbye to Oracle ?

[tweek]

I'm glad someone does. This was a situation where a former Great Plains/Solomon consultant who had being doing side work for the company for years sold our non-tech savvy CFO on Navision.

The problem is this:

While we qualify for a midsize company in terms of staff, our revenue and accounting volume ranks in the Fortune 100 range. Navision was a shitty choice from the start.

Re:Goodbye to Oracle ?

[tcopeland]

> took 8 hours to restore!

You may want to check out the comments about the "checkpoint_segments" configuration parameter here; tweaking that appears to improve bulk loading performance considerably.

PostgreSQL is doing a fine job for my database, although it's a much smaller installation than yours. Only 4M records, but, hey.

Re:Goodbye to Oracle ?

[IpalindromeI]

and walla Oracle's waiting there

Walla? Walla? You have got to be kidding.

Re:Goodbye to Oracle ?

[Anonymous Coward]

We have about 150 Oracle 9i's on Linux on 150 different locations vs. one Oracle 9i on Solaris serving 450 different locations. It's all a matter of cost and project's own specifications.

Re:Goodbye to Oracle ?

[Zerbs]

Actually I believe that PostgreSQL and Oracle could be a very complimentary setup. Keep Oracle for the mission critical applications and large data warehouses, while using PostgreSQL for smaller datamarts and ancillary applications. Since they have a simmilar architecture in terms of designing tablespaces, PostgreSQL's new 8.1 features like bitmap indexes and such moving even closer to Oracle's capabilities, and a simmilar procedural language for triggers and stored procs, I can easily see Oracle being used for enterprise wide purposes and PostgreSQL being used for workgroup purposes.

Re:Goodbye to Oracle ?

[ckswift]

Have you tried some of the tips in this?

Populating a Database

One may need to insert a large amount of data when first populating a database. This section contains some suggestions on how to make this process as efficient as possible.

Re:Goodbye to Oracle ?

[tweek]

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.

Re:Goodbye to Oracle ?

[tweek]

Actually all of these things are done by the pg_restore. It uses COPY and it also creates constraints and indices AFTER the data is loaded. This database is huge and I don't expect it to load in 20 minutes. The joy of it being a warehouse is that we CAN reload it from scratch as long as we haven't purged any data from our production system.

The only thing I'm going to do next is to disable fsync during the process and make note in our process documentation that it should be done that way for future restores. It'll be interesting to see the results there. I'm not worried about power failure or anything of that nature. This box is fully redundant and the SAN it's attached to is as well. IF we loose power to both circuits on the SAN or the box, then IBM has some explaining to do at the datacenter level.

Re:Goodbye to Oracle ?

[tcopeland]

> Actually that WAS done

Ah, OK, cool.

> 48M rows

Whew! That's a monster. And yup, hopefully autovacuum will be nicer.

> Greenplum has contributed some AMAZING changes back to postgres

Very, very cool. And thanks for the informative post. I've just converted all my PG databases to 8.1 and I'm happy to hear that it's got so much good stuff in it!

Re:Goodbye to Oracle ?

[jadavis]

Interesting comment.

However, you could provide a little more constructive criticism. For instance, if a PostgreSQL developer read "[DB2] has its warts and bugs but it's 100 times more robust than PostgreSQL," what might he do to correct that problem? Does PostgreSQL crash? The statement is a too ambiguous. Are you saying that runtime configuration of memory settings and faster dump/restore are reasons that DB2 is more robust?

Re:Goodbye to Oracle ?

[jadavis]

Vacuums are a killer for us.

Have you tried the vacuum delay to prevent the VACUUM from slowing performance of concurrent queries?

Re:Goodbye to Oracle ?

[tweek]

Actually I didn't mean for this to be a jab at PostgreSQL from a PostgreSQL sucks and Oracle/DB2 rocks perspective.

It's all a matter of thinking. One of our new DB2 dbas seems to be dead set against any opensource database. Based on his comments, I understand where he's coming from even if it's illogical.

In conversations we've been having today, it boiled down to a matter of opinion on the development side. Here's a couple of examples:

Binary backup vs. SQL backup - From a migration and upgrade standpoint, doing a sql level backup is much more portable. I don't have to do a UNLOAD/LOAD to move from platform to platform or major version to major version. This is what we're doing now.

But from a daily backup/restore perspective, a binary, block-level backup would win hands down. It's just not as portable. We recently migrated from DB2 on Linux/x86 to DB2 on AIX/Power. We had to go through a very detailed and high-risk process to migrate the database. In all of our trial runs, there were cases where the DDL was missing an index or something similar because of a bug with db2look or the order of object creation. In the case of the migration, a SQL level backup like mysql or pgsql uses would have saved us a TON of time and headache.

I can't tell someone they have to wait 8 hours if we have a botched warehouse load and have to restore from backup. In those cases, a binary backup would be MUCH faster. In the end a choice of engines would be prefered. Our daily backups can be binary but in the case of this new hardware and version upgrade, we could go with the SQL backup.

Another area that's reminds me of monolithic kernel debates, is that of memory management and data caching. DB2 and Oracle (Oracle I think as well) use internal memory segments called bufferpools to cache data for future reuse. Up until recently, I would have said that was a stupid idea because, unless you're using raw volumes and bypassing a file system cache, you're taking a double hit on memory. With DB2 8.2 (stinger), you can create tablespaces with a NO FILE SYSTEM CACHING. This avoids that double penalty.

With postgres, it relies VERY heavily on the OS to cache the data on the filesystem. This is in some cases a poor idea because the OS will cache the blocks read and not the actual row data. In the bufferpool scenario, the database will cache the actual read rows instead of the chunk of disk that held the data. You have less useless data sitting in memory. It's just a bit more intelligent.

During the above mentioned 8-hour restore, all 16GB of memory was in use and I have a very sneaky suspicion that the majority of that data would never be used again. When you have an OS like linux or AIX that is VERY aggressive at file system caching, this could cause problems.

I think every database on the market has a place. That includes SQL Server. The only point I was trying to make is that some design decisions on pgsql or mysql, really default it to a different market segment.

Re:Goodbye to Oracle ?

[tweek]

We've actually considered doing full vac. analyze during the day after our automated reporting has finished generating in the mornings. This would really help us out because there's not a lot of ad-hoc queries to our warehouse. We really limit who has access to that because it takes one stupid finance person with a GUI query tool to select every row from one of our largest tables to bring things to a dead standstill.

Here's a couple of row counts from some of our bigger tables:
financial_detail_info: 64906276
loan_account_agg_fact: 48078504

Also every single active account in our system gets updated every night because every single active account will accrue interest. This means several of these large tables have a large portion of the rows updated.

Re:Goodbye to Oracle ?

[jadavis]

But from a daily backup/restore perspective, a binary, block-level backup would win hands down.

Absolutely. PostgreSQL can do that with Point-In-Time Recovery, though unfortunately not between versions, which is a common situation. However, it would help you in your "botched warehouse" situation.

The more general problem that PostgreSQL needs to solve is that they need to be able to upgrade in-place disk structures rather than requiring dump/reload between minor versions.

With postgres, it relies VERY heavily on the OS to cache the data on the filesystem.

Very true. It makes me wonder how large the structures are for cache management are in a per-row caching system. Seems that you would have a smaller space for actual cached data, but a larger cache management structures. The cost for a cache miss would be the same though, since reading a block is about the same as reading a tuple from disk. Overall performance could only really be determined with numbers I suppose.

Re:Goodbye to Oracle ?

[tweek]

It's situations like this that I wish I could contribute beyond making vague suggestions. Here's hoping a postgres developer gets wind of this thread and can tell me if these were things that weren't thought of or if there are valid reasons for not having these various features. I consider (and my opinion is worth f-all in most situations ;>) these to be enterprise level features. I don't expect them to change the method of data caching but I think the backup idea has some merit.

Re:Goodbye to Oracle ?

[jadavis]

It sounds like you know what you're doing, but I have to ask: are you sure you need to do a VACUUM FULL ANALYZE and do you understand the difference between that and just VACUUM ANALYZE? I can see why VACUUM FULL would kill your performace, it has to actually move tuples around on disk. A normal VACUUM just updates the free space map (FSM) and reuses the dead space.

I have a somewhat large table (~10M fairly wide rows, low updates). A VACCUM ANALYZE run takes a few minutes (I haven't measured in a while), but it doesn't seem unreasonable, and with the delay it doesn't kill other queries in the process.

Re:Goodbye to Oracle ?

[jadavis]

Yeah, I think they are working on some of these things, but they are hard problems.

You can do hot binary block-level backups using PITR, but it won't work across versions of PostgreSQL. I think they want to make it work across versions, but it'll just take work.

The caching issues are probably not going to happen for a while. That is a lot more work, and it's less portable, and requires a long time of performance testing and so forth. DB2 will probably have it's place in your organization for a while.

Re:Goodbye to Oracle ?

[tweek]

The full was simply because of the amount of disk space we were reclaiming each night. I mentioned only the two tables but there are probably 4 or 5 fact tables that are close to that size. Disk space is cheap but I don't want to get caught with my pants down in the middle of the night.

This is also the interesting thing about the opensource database world. In that environment, one of an opensource database, many times your sysadmin will know just as much about the database as the dba. Many linux sysadmins have also used and managed various mysql or postgresql databases on the side because they could. Maybe it was for a weblog of some sort or maybe it was because they wanted to learn something.

Many things about our data warehouse I know nothing about. My job is to manage the systems and the networks but sysadmin positions are rarely constrained in that regard. The first person that people come to is the SA. The SA needs to know enough about what is ON his systems to say "Go to the DBA. He needs an index because I'm seeing so much I/O he must be doing a table scan or something" or "Go to the developer because the database isn't using any system resources right now and I've checked the basic of the database and there is no activity.". Many times the DBA will say that the developer needs better predicates. In our case, most often, we have bad SQL but I can't ignore the fact that I'm seeing "X" in the system and maybe I need to work in a bigger maintenance window so for the database.

Either way, we've run into issues where postgresql has had to build a 10GB temp table to get a result set as part of our warehouse load and it blew all of my capacity planning out of the water. We could have a busy Friday (Our business is retail financial) and could have 30k rows on each of 4 or 5 tables updated and we might end up having disk issues.

With the new hardware and my latest benchmarks, we can do a VACUUM ANALYZE each night and I've overallocated space and spindles so we could put off the FULL to a weekly.

Re:Goodbye to Oracle ?

[tweek]

That's why I wish I could help. I'm not really looking for us to replace DB2 anyway. I'm just wanting to make PostgreSQL perform the best I can. I also really want it to be the best database it can be. I really spend most of my time dealing with the warehouse when it comes to ETL or BI. To its credit, Actuate has been VERY supportive of us using PostgreSQL as our warehouse. When we had ODBC related problems (mostly with DataDirect), Actuate made application level changes for us to work around the bug. I just needed to be able to translate it for them. Informatica with all its warts worked with us as well. All of this in spite of the fact that neither mysql or pgsql was a supported database.

I think those industries are understanding that people aren't going to shell out for a DB2 or an Oracle just to run OLAP. I would argue in most of those cases that they are overkill. I also think pgsql gives the most clean skill translation from those other databases than mysql does.

Re:Goodbye to Oracle ?

[jadavis]

But why do you even need to do a FULL? VACUUM doesn't release the space back to the filesystem, but it does mark it for reuse by PostgreSQL. That means you aren't wasting space, because the dead tuples from updates/deletes are reused the next time you update/insert.

VACUUM FULL is only if you need to return the space back to the filesystem. It physically moves tuples on disk, so it's very expensive.

Re:Goodbye to Oracle ?

[tweek]

That's the point. We needed to return the space back to the filesystem. At this point I've added another 4 73.4GB spindles to the array so I've got some room to grow now. At the time, I needed to reclaim the dead tuple space. Of course on this new server, I'm allocating even more spindles and space. I've also got a ton more memory and horsepower to work with.

Re:Goodbye to Oracle ?

[jadavis]

Perhaps I'm not understanding. Why do you need to return the space back to the filesystem if your database is going to grow again anyway?

Regular VACUUM will mark the space as free and reuse it, so it seems like the same net effect. I can't think of any situation in which a periodic VACUUM FULL is needed. Normally, after you VACUUM, the file sizes will remain constant (because it's just reusing the dead space) until the table is larger than it used to be (when it runs out of dead space to reuse).

Re:Goodbye to Oracle ?

[Anonymous Coward]

I've had a problem with pg_restore running 10-20x slower than it seems like it should. When I needed to migrate a 13GB database from x86 to x86_64 I first tried with pg_restore and after leaving it to run overnight on a dual opteron 2GHz I gave up and tried a different approach. I dumped the db structure and table data separately to sql files. I split the structure into table definitions and constraints, then loaded first the definitions, then data, then added the constraints. The restoration process took a little over an hour. I find it baffling that the default restore command is basically broken. Still a postgres fan though.

Re:Goodbye to Oracle ?

[mw]

If you're using pg_restore it will exaktly do this, at least if you're dumping like this:
pg_dump -U .... dbname -Fc -b -f file.dmp

Restore:
pg_restore -U ... -d dbname -v file.dmp

Should exactly do what you want.

Re:Goodbye to Oracle ?

[JohanV]

We've actually considered doing full vac. analyze
...
This means several of these large tables have a large portion of the rows updated.

Don't VACUUM these tables, but CLUSTER them. VACUUM does in-place reordering while CLUSTER simply rebuilds the entire table and indexes and then swaps the pointers to the filenodes. If you combine that with a high value of maintenance_work_mem it can lead to a massive speedup.

Sun opening up?

[AntiDragon]

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?

Re:Sun opening up?

[Anonymous Coward]

Sun haven't been particularly enthusiastic about open source in the past.

The thing is, Sun has had to do a lot of work behind the scenes to get to where it is today on Open Source.

For example, it's about half a decade now since the project to open-source Solaris was started. There was an incredible amount of legal, engineering and commercial work to be done to get there.

These things don't happen on a whim.

Re:Sun opening up?

[Anonymous Coward]

You're right. However, wiring McNeeley's mouth shut didn't take long at all. That certainly helped.

I don't understand the slashdot rabble. They trumpet non-stop about the superiority of Open Source Ways, OSes and Apps, and then when an entity from the pay-space investigates and does indeed find benefits there, they fucking freak out, as if the Vendor has made a terrible mistake.

MySQL has some catching up to do but, as I've seen from using 5.0.15, catch up is exactly what they're going to do. And surpass; they're amazing developers. Companies coming from the pay-space are probably going to prefer Postgresql's BSD license and I say great, use it. I am not going to hazard a guess about the InnoDB thing and MySQL. Perhaps, rather than an 'Embrace and Extinguish' strategy by Oracle what we're seeing is the beginning of a parting of the ways between Oracle and SUN. You pay me the money those guys are making and I'll put together a report and submit it here.

Re:Sun opening up?

[Kunta Kinte]

Interesting. Could this be an indication of things to come?

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...

Re:Sun opening up?

[Anonymous Coward]

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...

Indeed. Sun is only just learning about PR (mostly the hard way).

Re:Sun opening up?

[jedidiah]

Um... you are trying to equate the general rabble with those of us that have actually supported production databases. That's absurd and dishonest of course.

We're not some "hegemony". We're a very collection of factions with conflicting experiences , sensibilities and interests.

I would love Postgres to knock the wind out of Oracle. A price cut would be very handy. I coulud spend some money on hardware rather than sending it all to Ellison.

Re:Sun opening up?

[killjoe]

Oracle is very affordable. It's free for single processor/small database uses and only costs 500 bucks for a dual processor license without replication. The price goes up as you pile on features of course but at the top level nobody else offers those kinds of features anyway.

If you really need the features of Oracle enterprise edition then you are going to have to wait a long time before the open source competition starts putting a downward pressure on the price.

Re:Sun opening up?

[cyberbob2010]

No, someone at Sun suffered from a partnership with Google.

I am seriously hoping that the two work even more closely together. Both are moving towards OSS and are looking to get more and more involved in the community as well.

Re:Sun opening up?

[jedidiah]

IOW, it's affordable if all you want to do is make small toy databases on your laptop.

If you want anything that's not going to blow over in a strong wind, you're going to be paying tens of kilobucks per processor.

I don't NEED Oracle to make a MythTV database. MySql already does better for that job.

If you're fixated on "feature richness" then you are a rube with no clue.

Sun Blog about improving performance

[IYagami]

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

Re:Sun Blog about improving performance

[bartash]

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.

Re:Sun Blog about improving performance

[zardo]

Postgres is a really nice database, but I think it's popularity is hindered by its crappy name. I propose a new name, like NuclearSQL or something.

Re:Sun Blog about improving performance

[einhverfr]

No kidding. But don't worry. I am sure that it is just because they are new to it and once more work with the community commences, they will do better.

I noticed that the responder to the blog was an active member of the PostgreSQL community and contributing developer. I think that this is a good sign.

Re:Sun Blog about improving performance

[Arcane_Rhino]

changing the block size used by the transaction log is something that should only be done by experts

Why? Doesn't this merely increase or decrease the sized of the TL before it recycles? As a n00b PostgreSQL administrator (non production as of yet) I am always on the look-out for information I may have overlooked.

I doubled the TL block size because I wanted to obtain a lengthy historical record. This was completed in the config file so the recompilation issue does not apply but now I am curious whether or not this will have unintended consequences. I have noticed no negative consequences but have not yet benchmarked very extensively.

Re:Sun Blog about improving performance

[einhverfr]

Why?

Ok. Changing this can be done by anyone, and should be done in the postgresql.conf.

Changing anything in the PsotgreSQL source should only be done by experts.

Re:Sun Blog about improving performance

[joib]

I believe that Sun incents its employees to blog.


Wouldn't surprise me if it's tacit. Say positive things about the company and products, advance on the corporate ladder, while publically they can honestly say that "hey, we're just encouraging our employees to get in touch with our users, be more open blah blah blah" or something like that.

Anyway, it's transparent enough that it's really nothing more than the dotcom version of infomercials.

Re:Sun Blog about improving performance

[JBird]

Or even better NuculurSQL!

I will tell you

[Anonymous Coward]

A woman can never be elected President of the United States for the same reason a gay man never will either - because they have both sucked a dick. No red-blooded man can say that someone who sucked a dick can be the supreme leader of the free world.

Also, because they are dumb whores.

Don't bother

[$RANDOMLUSER]

There's no point in calling Red Hat today, they're going to be in meetings all day, trying to figure out "What do we do now?"

That sound you hear, to coin a phrase, is Sun, cutting off Red Hat's air supply.

Re:Don't bother

[afd8856]

Since when we're glad that a major Unix developing company is killing a major Linux company? I believe somebody forgot to send me the memo

Re:Don't bother

[drinkypoo]

When that company is redhate? You know, the people who stopped putting out the distribution that many of us used and paid for (media/books, anyway) and expected to stick around, and turned it into a beta for a vastly more expensive product that cannot be automatically updated without paying for support? Let me get my party hat!

Wondering...

[Capt James McCarthy]

What Larry Ellison thinks of this announcement...

Re:Wondering...

[Anonymous Coward]

Especially since Oracle announced earlier this week that Solaris 10 would become their preferred platform ...

Which version

[Anonymous Coward]

Anybody know which version of Postgres they will supply? SUN have a history of including antique versions of things into Solaris (look at their Tomcat versions for instance).

What did you do in the database wars?

[Flying pig]

Microsoft (SQL Express) and Oracle have now produced free-ish low end versions of their databases to try and kill MySQL. Which gives a cheap Windows platform with a reasonable database for no incremental cost (MySQL is an incremental cost to deploy on Windows, and getting progressively more expensive.). Sun retaliates with PostgreSQL. There is clearly a big battle shaping up at the low end, and hopefully the winner will be the end user. The loser? Well, currently it looks like it might be MySQL. When we've finished digesting all the recent announcements, I suspect we may well be porting our application from MySQL to either Oracle or PostgreSQL on Solaris, for sound commercial and support reasons.

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.

Re:What did you do in the database wars?

[printman]

MySQL as SCO! :)

Re:What did you do in the database wars?

[Pengo]

"When we've finished digesting all the recent announcements, I suspect we may well be porting our application from MySQL to either Oracle or PostgreSQL on Solaris, for sound commercial and support reasons."

I have been running PGSQL on Linux since the 6.0 series. I would consider myself a prime candidate (small company, we run all of our customer service and core telecommunications service products (IVR) on top of the PGSQL database. I just don't see enough value-add to buy Sun equipment to run their flavor of PGSQL. I am not trying to flame or troll, or turf, whatever.

I just historically haven't had any problems running pgsql and don't honestly believe that having a sun engineer on the phone helping me fix a problem or running on solaris will really provide me any more stability than running RHEL3 Linux on Dell equipment. I would love to see a non-bias assesement of why I would want to switch to Solaris.

In my opinion, if they want to go after the small business or small databsae market they need to demonstrate:

1. How they really can bail you out of a tough spot.
2. How can solaris really make my life easier when I am reasonably comfortable using Linux.
3. Why would Postgres run better on Solaris than Linux? (advanced debugging capabilities seems like something that the pgsql engineers would want, but not me).

Re:What did you do in the database wars?

[danharan]

Dear Flying pig,

Sun supporting Postgres is not aiming at the low-end. MySQL will continue to develop features they told us we didn't need and Postgres has had for years.

Meanwhile moving to Postgres won't be that difficult. You'll probably find a few features that make it so you no longer need a few ugly hacks.

Re:What did you do in the database wars?

[Bishop]

RHEL3 Linux on Dell equipment.

In terms of hardware Sun's opteron servers are better then Dell's server. Opteron processors are faster and cooler then Intel Xeons. In terms of performance per watt (of heat) and performance per dollar Sun has the advantage.

The Sun hardware is always going to be fully support by Solaris. The latest and greats SCSI controllers will work. The nice lights out stuff is just going to work. RHEL3 support for Dell is always going to lag a bit. And you will run into problems where a RHEL patches breaks a Dell patch or vice versa.

I would not switch to Sun overnight. I will be waiting to see how committed Sun is to opensource Solaris10, postgresql, and opteron hardware. You should consider getting a Sun for your next dev server.

Re:What did you do in the database wars?

[einhverfr]

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.

To the more informed customer, MySQL radiates a sense of apprehension regarding data integrity (yes, MySQL 5 goes a long way towards fixing this but not far enough IMO). I would *highly* suggest going with PostgreSQL over Oracle for a number of reasons (among others, Oracle treats empty strings and NULLS as the same).

What is more interesting is that this is coming along at a time when MySQL is facing a great deal of uncertainty from the Innobase acquisition by Oracle. So MySQL is in a tough position right now. After all, who is still talking about MySQL 5 when they talk about MySQL? It seems to me a lot of air has been let out of that balloon.

I am not saying that MySQL is dying but they have been set back quite a ways by recent events. I am not sure they are in a position at the moment to respone effectively.

Re:What did you do in the database wars?

[Christopher B. Brown]

We have run into pretty big scaling issues on Linux; once you get to the point of wanting fibrechannel + disk array, you hit limits on Linux reliability pretty badly, alas.

One of our staff got really good at destroying Linux filesystems. Every variety was highly vulnerable; she'd pull one of the fibrechannel connections, and watch the systems fall down. Some of the problems were pretty nicely replicable on the Dell 6600 series on various media...

The thing I'd hope to get with Sun hardware + OS is actually two things:

• Firstly, I'd expect not to be getting Dell's "cruddy hardware of the week." Check anywhere: You'll find it deprecated. Google for dell postgresql performance and the first link you're likely to see is Hardware for best performance which quotes someone I work with :-).

  The Dell stuff has a history of underperforming compared to other hardware with apparently similar specs. It appears that their habit of buying whatever the hardware manufacturers are remaindering this week applies about as much to servers as to desktops, and the results suck.

• Secondly, hopefully Solaris plays a bit better than Linux as far as behaviour of filesystems under stress goes.

  We discovered with the fibrechannel situation that if you lose a cable or power, Linux has a habit of scribbling on things, thereby destroying data. Oops, if that was an important database, you're in trouble.

  I'm no raving BSD-o-Phile; my name is not Dave Gilbert; I use, and like, Linux plenty. Unfortunately, reliability in this area is something that is lacking. AIX played way better; that's what we're using, even though I'd rather put burning needles in my eyes than spend the day coding on AIX. (I don't even want to talk about shared libs on AIX... Ghack...)

That's not a straight answer to all of your issues, but hopefully it gives some ideas :-).

YYes! fp

[Anonymous Coward]

As one of the out of bed in the smells worse than a BSD addicts, flame 486/66 with 8 BATTLED IN COURT, to have regular by BSD-I who sell counterpart, Sorely diminished. share. *BSD is of America (GNAA) OUTER SPACE THE The failure of for a living got I won't bore you How is the GNAA I'm sick of it. open platform, come Here but now *BSD but FreeBSD Of its core achievements that I see the same fanatic known least of which is has been my only example, if you fucking market raise or lower the you all is to let reaper Nor do the walk up to a play effort to address took precedence counterpart, you all is to let corporate not anymore. It's = 36400 FreeBSD believe their

OS dependant OSS Support

[tronicum]

Suns way of supporting Open Source Software on their architecture ist quite interesting. With Support for Apache and PostgreSQL they have a full suite to support websides from small to enterprise (as PostgreSQL is a bit more "enterprise" ready).

What I wonder is if you should get such support and just use it as fallback for your problems on different architectures. That way you could test if your problem is specific to your setup and if you can reproduce it, you can use Suns fix and port it back to your real problem.

Are there any other big vendors with such specific OSS support?

This is beautiful.

[nighty5]

Although I am seeing some high-end financial-transactional based systems running Redhat lately, I am glad that Sun has its ear close to the ground.

I moved to PosgreSQL 2 years ago, and this has re-affirmed my confidence in Sun in embracing open source initiatives.

I guess it was absolutely something that had to happen, to re-invent yourself. IBM did it, Apple did it.

The future for Sun should be interesting in the next couple of years, I most certainly will be watching.

Maybe we should buy shares in Sun? Sitting on $3.68, Apple NOW sitting on $64.52.

Re:This is beautiful.

[Anonymous Coward]

> Sitting on $3.68, Apple NOW sitting on $64.52.

When will people learn that the price of a stock is completely arbitrary and means nothing. Look at this stock:

http://finance.yahoo.com/q?s=BRKa

It sells for $89,000 per share. Wall Street considers this attractively priced. SGI used to sell for 0.80 and anyone that owned that was an idiot as it was incredibly over priced. Learn about P/E and P/B ratios.

Re:This is beautiful.

[mikegre]

You can buy Sun options for 5 cents a share. In other words, for $1000, you can have the option to buy 20,000 shares of Sun stock. The options expire on
January, 2008. So if all the Sys Ad guys got together after they all purchased the options and decided to switch over to Sun, they would all become millionaires. We can do this.

Solaris worth trying for a redhat based system?

[slashmojo]

Currently using rhel (centos) on all servers but wondering if solaris10 is worth a look now.. is it fairly easy to admin? Is there an easy way to install and upgrade stuff along with a plentiful supply of the usual suspects to install?

Most times these days on centos I only have to run 'yum update' 'yum install blah' or 'cpan -i blah' with very occasionally having to do it manually or mess about a bit to get things working.. is it as trivial with solaris now or would I be spending twice as much time configuring and looking after the servers?

Probably safer to stick with what I (sort of) know but just curious about solaris.. last I used it was 7 or 8 years ago I think.

Re:Solaris worth trying for a redhat based system?

[Anonymous Coward]

The easiest way to install s/w on Solaris/OpenSolaris is using blastwave (www.blastwave.org) - for example, installing the entire KDE stack is done by :-

pkg-get -i kde

Simple enough? :-)

Re:Solaris worth trying for a redhat based system?

[slashmojo]

The easiest way to install s/w on Solaris/OpenSolaris is using blastwave (www.blastwave.org) - for example, installing the entire KDE stack is done by :-

pkg-get -i kde

Simple enough? :-)

Nice! Will have to give solaris a try now. Thanks.

Re:Solaris worth trying for a redhat based system?

[Dan Ost]

is it fairly easy to admin?

Only if you like java GUIs for configuration. We've got Solaris 9 on a dhcp server and can't configure it if we don't also have java installed because all the config tools require java.

I don't know if Solaris 10 is the same way.

Opensolaris is being done all wrong

[Anonymous Coward]

Sun is playing some silly "half ass" open source game when it come to opening up solaris. Until supposedly next summer, it won't be possible to have the full opensolaris code. By then it will be too late. And furthermore it's unclear whether Sun will be maintaining a commercial version of Solaris alongside OpenSolaris that contains every component worth having. Nobody wants to use subpar operating systems, especially if they have to substitute components, this also has the effect of eroding uniformity.

I'd love to try out opensolaris, but until maybe spring 2006 it's not a workable OS.

Re:Opensolaris is being done all wrong

[WindBourne]

First off, what they have not released yet, is work that is not fully tested. And they are releasing it as they feel comfortable.
Second, this is their commercial solaris. It is what is offered. They will sell you support on top of it. Basically, they are competing against Linux with this.
Third, while I am mostly a Linux hacker (and certainly where my loyalitys lie), Solaris is without a doubt a solid OS.

So my question to you, is why do you think it is subpar? Because, it does not have the latest and greatest in debug tools and Filesystems?

Re:Opensolaris is being done all wrong

[Anonymous Coward]

Because it does not have the latest and greatest in debug tools and Filesystems?

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/index .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.

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=12 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.

Re:Opensolaris is being done all wrong

[WindBourne]

that would be compared to reiserfs 3, not 4. There are some nice things in 4 that zfs will probably do in the future, but not now. Likewise, rfs4 will probably pick up some ideas from zfs in the future.

Re:Opensolaris is being done all wrong

[Anonymous Coward]

"Until supposedly next summer, it won't be possible to have the full opensolaris code. By then it will be too late."

OK, it's not the full code, but it's everything that matters: the kernel, system libraries, utilities... in other words, the "UNIX" part of Solaris, including stuff like DTrace and now ZFS. What they don't have open yet is provided in binary form, so you've got a complete operational version of Solaris to work with and hack on. What's missing that makes it "too late" for you, unlike the thousands of people who are already working with it?

"And furthermore it's unclear whether Sun will be maintaining a commercial version of Solaris alongside OpenSolaris that contains every component worth having."

Unclear to who? Sun continues to release and update commercial Solaris (i.e., Solaris 10 -- their "stable" release), they're providing monthly snapshots of the next release of Solaris, codenamed "Nevada," via Solaris Express (their "dev" release), and as I said above, they have a Solaris Express distro based on OpenSolaris. All of these contain every component of Solaris, which I have to assume would mean "every component worth having." If you don't think so, please give an example.

By the way, "It's unclear" is a blatant indicator of Astroturfing in progress.

"Nobody wants to use subpar operating systems"

And I suspect that's what's got you worried. So which subpar operating system does your company produce?

moD uP

[Anonymous Coward]

as those non gay, guys are usuualy they are Come

sun will need to make BIG changes

[sl4shd0rk]

Despite whatever flavor of the week they are licking.

- ditch the forte crap and vendor lockin scheme
- stop shipping your own bastardized Perl
- ultrasparc performance is terrible. Address it.
- get the X11 libraries and headers fixed - completely.
- find a termcap that works with the rest of the world
- fully support samba for chrissakes
- DROP the java front ends for everything. We get gray waiting for loadtimes.
- Get ldap working without so many support applications (clean up all the netscape crap or get rid of it)
- better yet, clean up the OS subsystem and make your platform work better with OSS software (eg: gcc)

Re:sun will need to make BIG changes

[Anonymous Coward]

- ditch the forte crap and vendor lockin scheme

Done. Sun released Studio 11 (http://www.sun.com/software/products/studio/index .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.

- ultrasparc performance is terrible. Address it.

Done. The UltraSPARC-IV+ chip (http://www.sun.com/processors/UltraSPARC-IVplus/) 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.

- 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.

Re:sun will need to make BIG changes

[assantisz]

- stop shipping your own bastardized Perl

Would you care to elaborate on this? The only reason why Solaris comes with Perl bundled is because many tools (like kstat, projtools, etc.) are written in Perl. It's a fully fledged distribution of Perl (5.6.1 on Solaris 8, 5.8.4 on Solaris 10) and works just fine.

Nothing stops you from installing your own perl in /usr/local or /opt, though. That's what I and many others do.

Re:sun will need to make BIG changes

[Anonymous Coward]

As the engineer responsible for supporting Perl in Solaris I'd be interested to hear why you think it is 'bastardized'.

Re:sun will need to make BIG changes

[IvyKing]

A lot of the /. crowd thinks anything that works slightly different from Linux is "bastardized", even when the Linux/gnu behavior is non-standard.

Now if they were talking about "awk" on Solaris...

And Oracle just endorsed Open Solaris

[davecb]

It looks like a little bit of convergance on a class of database (big) and a platform (big).

Independantly, Oracle bought the company the provides the innobase substructure for MySQL.

--dave

Is this bigger than ZFS?

[Anonymous Coward]

I can't believe this made the front page but the cool new ZFS filesystem didn't!

kill -HUP?

[coder111]

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

Re:kill -HUP?

[jsight]

Yes, that generally works. /etc/init.d/postgresql reload also normally does the same thing.

There may be configuration parameters that this won't reset, but I haven't changed enough during runtime to know.

Re:kill -HUP?

[ajs318]

"/etc/init.d/foo reload" pretty much always just sends a SIGHUP to the prime instance of foo {the one whose PID is kept in /var/run/foo}. But not every daemon rereads its configuration files when it receives a SIGHUP; which is why we have all these scripts in init.d, with a unified syntax across all of them.

Re:kill -HUP?

[jadavis]

Many settings require server restart, notably some of the memory settings.

Re:kill -HUP?

[jsight]

Yes, I'm aware of what /etc/init.d/foo reload normally does. :) Just pointing out that it may be easier for some Unix slackers than finding the right process id and SIGUP'ing it. And, of course, it's convenient for those occasional apps that can be forced to reload in other ways too.

I wonder what Oracle thinks about this?

[QuietLagoon]

Oracle has recently cozied up to Sun Solaris. I wonder what Oracle's reaction to this Sun/PostgreSQL announcement is, especially since Oracle recently tried to take out MySQL?

Re:I wonder what Oracle thinks about this?

[Dan Ost]

Does Oracle even see PostgreSQL as a threat? I don't think I've ever heard Oracle even acknowlege PostgreSQL's existance.

The only thing I never liked about PostgreSQL is..

[Anonymous Coward]

the silly name. I mean, what *was* wrong with just "Postgres"? It's a bit embarassing to be the open-source advocate and have to say silly sounding names like this. "How is that spelled?" Why do Linux people feel compelled to spell everything beginning with "gn", "k", or with some recursive acronym? Sigh...

PostgreSQL and C#?

[Anonymous Coward]

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 >_

swing

[porkThreeWays]

- 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.

Re:swing

[Anonymous Coward]

Event handlers are supposed to return immediately. If your task takes time, hand it over to a background thread..

Swing is a fairly nice api imho, the reputation of java apps, like vb, is ruined by lousy programmers.

Re:swing

[Hulfs]

What you're describing is not a fault of the Swing API or implementation, it's the fault of the programmer of your admin tool. Swing event threads are not supposed to run for extended periods of time. If your event handler kicks into a long running process you have to invoke another thread to handle this process because your current event thread is blocking the event pump from popping the next event from the queue (see utilities like Foxtrot or Sun's SwingWorker class). This is pretty widely documented across Sun's Swing tutorials, but it's something that is sadly almost never discussed in most other sources of Swing information (books/other tutorials).

Re:swing

[Billly Gates]

Which is why I like Eclipse's swt. The toolkit looks very native on windows as well since it hooks into a native windowing environment and its very fast.

Re:swing

[hackstraw]

Java is a great language. However, their poor implementation of the GUI API's makes the end user experience bad.

I'm glad to hear someone else with the same experiences and opinions of java that I have had.

I've dinked with the java language some, but have lost interest because of other choices. I've seen java apps that basically just suck for 10 years now, and I'm java gunshy now.

Oracle's universal installer wasn't very universal on win nt when the colors were greater than 16 or so. I've had java "web" installers or whatever they called them crash when trying to display over a remote X connection, and had to resort to a text base interface. I've seen a number of "null pointer references" when java is not supposed to have pointers. I've "debugged" java apps by instead of doing java /path/to/java.app I had to cd to /pat/to and then run the application (classpath issue). I've worked with Mathworks trying to get Matlab to display remotely over an X connection. That too was a java problem. I used a java bittorrent program, but had to quit using it because it used too much CPU and for some reason it would not work for more than one user at a time. I've had java crash netscape so many times, I stopped using it in netscape to enable me to see wavy images and scrolling LED signs. I've had java not work right under OS X for a very simple zoom applet.

Those are just things I've come up with off of the top of my head. I've heard people say its OK as a middleware glue tool between web servers and databases. I've never done that. I can say that in my experience, the java implementation has always sucked over the years, and if I never saw another java app, I would be fine with that.

Re:swing

[Anonymous Coward]

Swing == shite. But that's not all. Run any Java app and it'll quickly push every other app out to swap. Seriously... all Java apps are bloat monsters, there's something wrong with the language design or VM that causes... but all Java apps reduce your machine to a thrashing slug -- and that's quite apart from the extraordinary amount of time Java apps take to start (and yes, this is with 1.5).

I've read comments from so-called "java gurus" excusing the way Java functions and explaining how it doesn't matter because "that stuff gets swapped out" etc etc. All the excuses made assume that the Java app owns the machine (which may be true for server apps) and isn't running with dozens of other apps, as it is in most desktop situations.

The only Java app I'll tolerate is Azureus, and even that bloats itself to occupy %30 of system RAM in an hour of operation -- running anything else is an exercise in frustration. Don't even mention Eclipse -- Christ... I'd hate to think what would happen if I tried to run Azureus and Eclipse at the same time. My HD would probably have an epileptic fit from all the swapping... and this is on a 512MB PC.

It's about time Sun understood this and fixes the fucking problems instead of listing one tired shitty excuse after another.

Re:swing

[Anonymous Coward]

Why don't you limit the resident memory set size of your Java processes to something reasonable so that they don't interfere with other applications? C'mon, this was standard operating procedure on multiuser systems decades ago!

Re:swing

[Anonymous Coward]

1. It does. Azureus is run via a script which does just this.
2. Are you suggesting that, instead of being memory efficient, we should manually set every app's memory. How very DOS of you. Do you expect this wonderful scheme of yours (and let's not forget this is after a decade of "Java is great for desktop apps" bullshit from Sun and god-only-knows how many man-years of development), to fly? How fucking stupid are you... no wonder Java is only ever used for server apps.

How about, ohh I don't know, making it s that Java doesn't hog the whole fucking RAM for even simple programs? Hmmmm?

Re:swing

[Anonymous Coward]

1. It does. Azureus is run via a script which does just this.

Hey, make up your mind. You said that if you "run any Java app," "it'll quickly push every other app out to swap." If the Azureus script is already telling your OS not to allow a single process to negatively affect every other process, how is it happening?

2. Are you suggesting that, instead of being memory efficient, we should manually set every app's memory. How very DOS of you.

Nope. But I can't fix your programs for you. What I did do was suggest that you use existing OS functionality to work around the problem right now while you get the application problem fixed.

How about, ohh I don't know, making it s that Java doesn't hog the whole fucking RAM for even simple programs? Hmmmm?

Like I said, this is a known problem whose solution was known decades ago. If you were running a multiuser system with dozens of simultaneous logons back then, would you give them all unlimited working set sizes and then rail on some bboard against those dang users who insist on running all their memory hogging rebuilds during business hours? Or would you put some limits in place? What would your boss want you to do?

Re:swing

[Anonymous Coward]

Hey, make up your mind. You said that if you "run any Java app," "it'll quickly push every other app out to swap." If the Azureus script is already telling your OS not to allow a single process to negatively affect every other process, how is it happening?

You tell me! Azureus grows to occupy every single bit of the RAM that it is allowed to do... so does every other Java app I've ever used.

Nope. But I can't fix your programs for you. What I did do was suggest that you use existing OS functionality to work around the problem right now while you get the application problem fixed.

You don't understand (or, you do and are deliberately being obtuse)... every fucking Java app will grow to the full size it is allowed to do. Are you suggesting that I work out what Java apps I am going to run and partition up the machine in advance? I'll repeat myself: How very DOS of you... no wonder no-one wants to use Java for desktop apps.

Like I said, this is a known problem whose solution was known decades ago.

Of course it's known fucking problem... one whose solution is not acceptable on the desktop... which is why JAVA IS A MISERABLE FAILURE THERE. Java is spectacularly poorly designed -- I doubt Sun are incompetent enough to drag out such a miserable failure for this long, unless they are simply unable to solve it (without such Heath Robinson techniques as manually specificing the maximum size allowed for each app) due to a fundamental design flaw.

That's amusing.

[Anonymous Coward]

"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.

Re:That's amusing.

[IvyKing]

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 just downloaded Sun's Studio 11 package, no license manager in sight (which, iirc, stopped with Workshop 6 Update 2). The software is available for a free download, but support will cost you (which makes sense). Sun's compilers have usually given much better performance than gcc on Sun hardware and appear to give better performance on the Opteron as well.

BTW, Sun's first 64 bit compiler shipped about the same time as Solaris 7, late 1998.

Free versions of Solaris, free compilers and competively priced Opteron workstations...

Re:That's amusing.

[Anonymous Coward]

I just downloaded Sun's Studio 11 package, no license manager in sight (which, iirc, stopped with Workshop 6 Update 2).

Yep, Workshop 6 Update 2 (from 2001) is the last release
which used the license manager. Not that the license manager could interfere with gcc in any way, as certainly gcc does not connect to any license manager.

Thomas

I deal with Sun a lot

[Anonymous Coward]

What you say is true, but not complete.

The factions in Sun continually swap positions. I think they have a bi-weekly meeting of VPs where they pull "Hate M$", "Billy G. is our friend", "Love Linux", "Kill Linux", and "BSD Rules" cards out of a hat then push that position until the next drawing.

Then, just for fun, they completely reorg the company every month.

Postgres was an Object Oriented Database

[brokeninside]

When they made the Postgres engine SQL compliant, they changed the name to PostgreSQL.

Sun seems to finally be getting it.

[dghcasp]

On a somewhat related topic, I received an email recently saying that Sun's developer package is now free, instead of $3000.

Finally. Sun hasn't shipped a C compiler with its OS since SunOS 4.1.3 (circa 1990).

Re:Sun seems to finally be getting it.

[nodrogluap]

Which is great, because in my experience gcc has a bad backend on Solaris. When I compile with cc instead of gcc, I often see a 30-50% reduction in process execution turnaround time, while using less CPU too!

Anyone who compares two apps on sparc-solaris and x86-linux should really keep this in mind...

Re:Sun seems to finally be getting it.

[drinkypoo]

It makes sense - sun was only hurting themselves by not providing a free toolchain. Since gcc's sparc code is so much slower than sun's, it made slowlaris look even slower than it really is. Meanwhile x86/linux was kicking solaris' uniprocessor performance right in the ass because that's what gcc does best, x86 code...

Re:Sun seems to finally be getting it.

[Anonymous Coward]

You mean other than gcc of course, since about Solaris 8.

Re:Sun seems to finally be getting it.

[Anonymous Coward]

it made slowlaris look even slower

Hehehe! Do you mind if I use that myself?

Meanwhile x86/linux was kicking solaris' uniprocessor performance right in the ass because that's what gcc does best, x86 code...

I thought gcc was pretty portable? Doesn't it run on SOLARIS x86?

Re:Sun seems to finally be getting it.

[mikefe]

Which is great, because in my experience gcc has a bad backend on Solaris. When I compile with cc instead of gcc, I often see a 30-50% reduction in process execution turnaround time, while using less CPU too!

Anyone who compares two apps on sparc-solaris and x86-linux should really keep this in mind...

Not to mention that most of the base libraries are completely different in Solaris and Linux, at the very least libc is different.

Re:Sun seems to finally be getting it.

[drinkypoo]

gcc has run on solaris x86 for a long time. but, most people are interested in comparing solaris/sparc to linux/x86 or linux/x86-64 because let's face it, there's little to no reason to run solaris on x86.

Niagra (UltraSPARC T1) *screams*

[Anonymous Coward]

For integer ops, anyway. For FP ops, well, it sucks. But that shouldn't matter for things like web servers and most DB apps.

http://www.sun.com/processors/UltraSPARC-T1/index. xml

32 simultaneous threads of execution, 72W to drive the chip. How much power does a quad Zeon draw?

Dell's gonna shit their pants.

It's too bad you got modded "flamebait"

[IANAAC]

It IS an honest question.

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).

Re:It's too bad you got modded "flamebait"

[Anonymous Coward]

I see Oracle 9iR2 released for Solaris 10 SPARC 32-bit and 64bit. And Oracle 10g, RAC and non-RAC, is available on Solaris 10 for SPARC and x86. Solaris is an Oracle base platform, so I'd be very surprised it weren't supported.

I only checked a few products and platforms, so this is not a complete listing.

You can check platform certifications at:
https://metalink.oracle.com/metalink/certify/certi fy.istore_welcome

Debian Solaris

[Doc Ruby]

How is a "Red Hat binary" different from a "Linux binary"? What will it take to make Debian Linux binaries run on Solaris 10 with this Container tech running? Will Debian Linux binaries run on Debian Solaris with the Container running?

Re:Debian Solaris

[TheRaven64]

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'.

Re:Debian Solaris

[Doc Ruby]

I think distro-specific support also means dependency on a distro's filesystem directory structure (where apps find called binaries/executables, including libraries). I suppose a system of symlinks can replicate any distro's dir structure on any other distro. I wonder if there's a script that creates those cross-distro symlinks, and if there's a "Grand Unified Structure" that would allow access to any distro as if it were any other.

Re:Debian Solaris

[twiddlingbits]

Eh? Why would you want to do that? Solaris 10 performs so much better than Linux and gives you Dtrace to figure out what is going on when things dont run well. You would not realize the performance gains if you ran Linux as a Container under Solaris 10 and then ran Linux binaries.

Re:Debian Solaris

[Doc Ruby]

Because I have lots of Debian software that I need to run. I have things I need to do in my work. I pick the apps that do that work. That determines the OS, that will run those apps. In turn that determines the hardware. I have secondary considerations like cost that determine the choices at each of those layers, when I have choices. So now that I have the option to run Linux apps on Solaris, I have the choice of whether it's better for me to run those apps on Linux or on Solaris. My decision's performance factor is based on comparing whether the Linux apps on Solaris are performing adequately to my needs, and whether they're performing much worse than they do natively on Linux. If the Linux OS performance improvement outweighs the other Solaris benefits, that factors into my decision. If I'm not getting the performance from Solaris that native apps get, that really doesn't matter. Except that it offers another option: porting the Linux apps to Solaris, which is easier running both under Solaris.

The point is that the apps we have determine our OS, after factoring in the values of the alternative choices we have. Linux apps on Solaris gives me valuable options.

Re:Debian Solaris

[Anonymous Coward]

Three of the obvious problem areas are
- system calls
- binary compatibility with certain versions of libraries
- configuration files

Providing the (Linux) system calls required by a "Linux" binary looks somewhat doable. Providing all those system configuration files a binary might expect, and then have the whole thing work correctly, looks quite difficult. And as the system configuration files are significantly different between Linux distributions, any "Red Hat container" is unlikely to be sufficient to run a Debian binary.

Thomas

Re:Debian Solaris

[Doc Ruby]

The syscalls are not just "somewhat doable", those syscalls are binary compatible across all distros, as they all share the same Linux kernel. That's why the distros are called "Linux". The only reason, actually - Stallman's insistence on calling the OS "GNU/Linux" is finally validated by these shuffled kernel/OS combinations.

If the "Red Hat" container can run RH binaries, what stops you from installing Debian libraries in Debian-named directories with Debian config files? That's most of the Debian Solaris OS. So that implies that Debian Solaris 10 Linux binary compatibility is highly feasible, if not workable out of the box.

Re:Debian Solaris

[twiddlingbits]

I assume you are not running a large organization with 100's or 1000's of users where the performance hit would mean something. If your apps are resource intensive you might need bigger hardware might be the downside of doing Linux under Solaris. What apps do you have that are not able to be ported as binaries or recompiled to take advantage of Solaris 10?

Re:Debian Solaris

[Doc Ruby]

I conclude you are not reading my posts very carefully. As I said, if the Solaris execution of Linux apps is at least as fast as their native Linux execution, then it's not a performance hit. To the contrary, if porting them to Solaris then increases their performance beyond their native Linux OS performance, then the move is correct. That is the correct development procedure: use as much of the running SW as we can, then make the least changes with the least risk.

I'm actually targetting millions of high-availablity users with the apps we've developed under Debian. If I can run on a serverfarm of several thousand T1 servers, rather than on Linux, and get all the Solaris reliability/support benefits, I want to do that. Of course if the performance hit from Linux to a Solaris Linux Container is significant for the same dollars, it might not be worth the cost. It might still be worth porting, where executing the Linux apps on the Solaris machine will be very useful in porting. The least recompiling and porting is the best, if the costs are either zero of minimal.

But now I'm just repeating myself and stating obvious development economics and management principles. Simply, Solaris offers significant benefits, with possibly minimal costs, and several options. I'm starting with Debian apps, which now might run on Solaris. Ergo, I'm trying to identify the costs and risks of running the Debian apps on Solaris. That is a sound strategy, as evidenced by Sun's release of the container. The question is just what are the relative costs:benefits*risks of executing it, as always in any strategic decision.

Re:Debian Solaris

[Anonymous Coward]

Binary compatibility is not just kernel system calls,
but also any shared libraries which ship with the OS.
Binary compatibility means that you can roll out your existing application as it is, no recompilation, no reconfiguration, no shipping of additional libraries, just a little bit of additional testing.
It also is not true that there have not been any
interface changes in the Linux kernel, there have been quite a few.

Sure, this probably won't hurt you if you run "hello, world"
as your only application. But
there are applications out there which use hundreds of different system libraries. There are applications out
there which depend on multiple OS services to work properly. I have seen quite a few applications, which worked perfectly fine on one Linux distribution, get broken on another Linux distribution (same kernel, same glibc).

Sometimes, that other Linux distri has some critical bugs, or ships some older version of some essential library.
I still remember Red Hat 9.0 and earlier not even booting
up after an application was installed which uses the LSB installation method (broken in those Red Hat releases).
Or the fancy problem some other software had on Red Hat AS 3.0 because somebody dumb at Red Hat had decided to change vixie cron such that it would allow empty crontabs (without documenting the change, of course).

Sometimes, the application cannot make the changes to system configuration files it needs to make during installation
(because the files are located elsewhere, or have a different syntax). Meaning, if you would want to set up a "Debian container" on Solaris, and you had a Debian application which changed system configuration files, your "Debian container" would have to translate to Debian side configuration file changes into system configuration file changes for the underlying Solaris OS.

Thomas

Re:Debian Solaris

[Doc Ruby]

What binary kernel API differences are there between Red Hat's bundled kernel and Debian's, at the same kernel version?

And, as I said you can install on the Solaris RH Container any missing Debian libraries, what binary API differences remain?

Again, as I said you can install on the Solaris RH Container any missing Debian directories/configfiles, what other API differences remain?

In short, is there any more to be done to the Solaris RH Container than installing Debian libraries/directories/configfiles to make it a Solaris Debian Container? And hasn't that already been substantially done in the Debian Solaris project?

Re:Debian Solaris

[assantisz]

This is from Sun's website:

[...] By allowing Solaris and Linux binaries to co-exist on the same system, cross-platform application testing and deployment is simplified. In addition, it is now possible to use the award-winning dynamic tracing (DTrace) capabilities of Solaris 10 to monitor and help debug Linux applications, [...]

As you can see you can use Solaris's native tools (including DTrace) to debug a Linux application. This is huge!

Re:Debian Solaris

[Anonymous Coward]

You seem to assume that a "Red Hat container" somehow is a Linux distribution. As I interpret Sun's announcement, a "Red Hat container" is something like a Solaris zone. A zone running a special Solaris kernel, a Solaris kernel which accepts a certain set of Linux kernel system calls, and Solaris services and libraries which accept Red Hat style OS configuration files.

I don't think that you can put normal Debian configuration files on top of that. Surely you can install the files, but one would expect the OS to simply ignore them. If I put a few boottime scripts into /etc/init.d/rc5.d, I would expect Solaris to simply ignore them, as it does not look there for boottime scripts. Debian/Solaris, that might possibly work, because after all there still is Solaris running in that zone. But if the Debian/Solaris project is successful you won't need Sun's "Red Hat container" for that.

Thomas

Re:Debian Solaris

[Doc Ruby]

I don't think the RH Container is a Linux distro, per se. I think it's a zone, as you say, wherein a RH binary RPM can run - a Linux compatibility layer for the Solaris kernel, like the one in NetBSD. Maybe it's not enough to boot from Debian configs, but that's not necessary. All that's necessary is that a booted Solaris can run RH binaries, which the container seems to offer.

But I've got Debian binaries. So, if I install Debian libraries, and mame a Debian dir structure (mostly symlink maps) containing Debian configfiles, will the container run Debian binaries? That's the point: to run Debian binaries on Solaris. It seems that the Debian Solaris project, already fairly successful, goes a long way towards the necessary libraries and dir structure, installed along with a Solaris kernel. The question then is how much more is necessary?

Re:Debian Solaris

[Anonymous Coward]

From this angle, I would expect that you can get "normal" Debian binaries to run, as long as your Debian is reasonably close to whatever Sun will provide in that "Red Hat container" (Probably AS 4.0 compatibility, what else could that be?). Something Debian which just brings its own private configuration files, or does not have any configuration files.

But something which tries to start certain services available on Debian, tries to reconfigure those services, installs boottime scripts and so on I would expect not to work out of the box. If its just one or two scripts which need to be adapted, that might not be too difficult to get to run with a little bit of effort. Or somebody else such as the Debian/Solaris project might have done that already.

Whereas something which tries to start non-exotic services available on Red Hat, tries to reconfigure those services the way they are configured on Red Rat, installs boottime scripts and so on I would hope to frequently work inside of that "Red Hat container".

Thomas

Nope - this is Sun's revenge at IBM

[Kenneth Stephen]

Lets face it - Oracle isnt kicking Sun's butt - its IBM. Ever since the dot com bubble burst and IBM finally found its game, the sun has been setting (or eclipsed (ha-ha!)) with IBM stealing more and more of Sun's customers and grabbing new accounts. Part of the problem for Sun is that IBM has the ability to sell solutions. You want a software stack to handle applications? IBM has it (WebSphere, DB2, etc). You want a software stack to manage infrastructure? IBM has that too (all the Tivoli stuff). You want office productivity infrastructure? IBM has that too (Lotus stuff). And along with all these go IBM servers.

This is Sun's attempt to come back into the market by saying - hey - we have a database solution too. Next thing you know, they'll be throwing their support behind (or buying out) a vendor of J2EE containers.....

Re:Nope - this is Sun's revenge at IBM

[psykocrime]

(note: intentional over-simplifications included below, due to time constraints, use this comment at your own risk)

Parent has hit the nail on the head. Selling solutions and going "up the stack" is where it's at... If you can sell the components of "the stack" as part of a comprehensive solution, you're golden. IBM has the broad product line to cover almost everything an enterprise needs, and they may be the only company in the world who are as well positioned in that regard. Oracle is getting better in that area, with all their recent acquisitions, and Computer Associates has a broad product line, but neither manufactures hardware or has the consulting / services arm to match IBM. The main thing IBM doesn't have now is "applications" (think, HR, ERP, MRP, Financials, etc) but they have partnerships to be able to provide that stuff.

If some of you guys really want to make some money, put together a company to sell a complete "enterprise" solutions portfolio made up of open-source software, acquire SGI for hardware (their market cap is only about $112 million, and their last 10-Q mentions looking for an acquirer), and hire as many talented F/OSS developers and admins as you can before JBoss gobbles them all up. Then emulate IBM's model - hardware, software, services - but focus on the SMB market who don't *quite* need the high-end capabilities of IBM's software and servers.

Postgres - Oracle?

[Doc Ruby]

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"?

Re:PostgreSQL and C#?

[GooberToo]

You can write SP for PostgreSQL in some half dozen languages...perhaps more, but I would be very surprised in C# were one of them...at least at this point. IIRC, Java is now an option. With so many language options already available for PostgreSQL, do you really need C# in the mix?

Sun and BSD

[alexhmit01]

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

Re:Sun and BSD

[WindBourne]

First off, I have worked for IBM and HP.

BSD is corporate friendly, iff you want the same game that has all but destroyed the unix market. That is, the ability to close off the work from your competitors as soon as it is in your advantage. Personally, the whole fiasco over unix taught me that it is a losing situation and one that I will no longer do. GPL works better for suppliers as it prevents anybody from being able to take away and not give. It is also better from consumers as it prevents one company from winning the whole thing and then charging at monopoly prices. But BSD license is a great deal for any company that wants to own a monopoly.

My issue with Sun is that they have not dealt with BSD for the last 20 years. Suddenly, they are back working with them??? uh uh. Does not really make sense.

As far as Linux and tech. goes, While they borrowed heavily from unix for the APIs, the internals are radically different. So different, that Opensolaris was internally benchmarked against it and was losing to Linux (network AND filesystem) and had to undergo massive re-working (borrowing from Linux). That is why they were late to the market.
BTW, that is not a slam on Sun (I have nothing but the utmost respect for them). That is credit to Linux that you seem to not want to give. One of the biggest differences between Linux and the rest of the market (including BSDs), is that we really are in the open. Everybody else who likes to claim that they are open ALWAYS has something held back.

Must be lonely

[Anonymous Coward]

Being the only one at Sun who knows what's going on around you. :-)

PostgreSQL is a NICE package...

[alexhmit01]

We moved from MySQL to PostgreSQL a few years ago, and couldn't be happier. The secret is to do it intelligently...

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 := 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.

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

Re:PostgreSQL is a NICE package...

[jadavis]

the connection costs kill you

If the connection time is significant, just use PgPool. It uses the PostgreSQL protocol itself, so you don't have to change your application at all.

Re:PostgreSQL is a NICE package...

[bovinewasteproduct]

Well, running a SELECT COUNT(*) on the threads JOIN topics will BE BALLS slow on PostgreSQL.

Have you tried it with 8.1? If you've got your indexes setup properly, it's ALOT faster than it was (used to require a seq scan, but now uses an index if available). In general, 8.1 is alot faster than prior versions, especially if you take advantage of the the bells and whistles (e.g. prepared transactions, tablespaces and auto-vacuum).

BWP

Re:PostgreSQL is a NICE package...

[Nivag064]

I am curious, which versions of Postgres are you referring too?

I guess you are talking about the 7.x.y versions. Have you tested 8.1 for queries, I know a lot of work has gone into optimising queries and making better use of indexes.

You wrote one of the rare Slashdot articles that actually gave me a lot of useful ideas to followup - or should I complain that you got me thinking too much?


Thanks,

Nivag

When Sun didn't want to compete w/Oracle ...

[jlrobins_uncc]

I remember attending a presentation from Sun personel demoing their portal mail system, how they prided themselves at not competing with the application providers who develop for Solaris. I remember Oracle was mentioned specifically by name. They provided a counter-example in Microsoft, who produces both SQL-Server and the operating system.

Oh well.

So confused -- Sun becomes more evil by supporting PostgreSQL ?

Re:PostgreSQL and C#?

[Slime-dogg]

Why not? Seriously. The more languages, the better. That way, programmers can code in whatever they are most comfortable with.

Not so good.

[TheLink]

"HOWEVER, you need to learn to spend more time programming your database... However, you will spend LESS time programming yours sites/applications... It's a tradeoff"

That's fine if you just have a small site - one or a handful of servers.

The trouble is webapp CPU is much cheaper than DB server CPU. You can very easily keep adding webappservers and hook them to your DB server.

But AFAIK you can't add capacity as easily or cheaply to your DB server. Please do correct me if I'm wrong - give me links.

Of course Sun will be happy to provide the 64 CPU 128GB single system image server for your database (with attached storage etc), if you end up needing it - which you might if you start running a lot of PHP in your database.

So whilst I'm fine with doing stuff in the DB (esp to maintain data integrity), I don't think it's such a good idea to put so much processing in the DB, especially if the language doesn't perform that well (has PHP improved in speed significantly?).

Re:PostgreSQL and C#?

[Anonymous Coward]

Exactly, I am confortable with C#, I learnt java in school, I did some applications and web app in java, I did a training session ( don't know how it's called exactly in english ) of 4 weeks about java, and I hate this language with a passion, in fact as much as php or VB.
I dislike other languages too, I tried out perl, C / C++, vb and php ( obviously ), I appreciated that oracle was supporting now developpement of stored procedure in C#, I didn't really go far not much time, but in comparaison of PL/SQL, it was really interresting.

Re:PostgreSQL and C#?

[jadavis]

PostgreSQL is very extensible. There is currently no pl/csharp, but adding such a language is not an invasive change. There is a "CREATE LANGUAGE" command that lets you create the procedural language of your choice by supplying a C handler function.

Of cource, you need to be able to embed the interpreter. I think if you did, you'd get all the languages that are part of the CLR.

Re:PostgreSQL and C#?

[codepunk]

So let me get this straight you hate java but you love C#. The two languages are damn near identical. What you are really trying to say is you seen some MS marketing material that said C# was really great so you believed it.

Re:PostgreSQL and C#?

[Anonymous Coward]

1/I prefer much more visual studio than eclipse.
2/I hate having an useless framework.
3/For me there is strickly no difference between C/C++ and java ( see point 2 ).
4/C# and java are at the same time close to each other and totally different.
5/Licence wise, to have the same feature than the .net framework, I have to use lgpl or worse gpl library if I don't want to spend 80% of my time developping librairies.
6/Javadoc is not really useable.

Re:PostgreSQL and C#?

[Anonymous Coward]

Actually, there is a project for this ... the PL/mono project.
It's a bit stalled at the moment, though. Maybe you could help out?

About Time PostgreSQL Gets Serious Recognition

[Austin Milbarge]

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.

Application tuning suggestions

[einhverfr]

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.

Re:Application tuning suggestions

[TheLink]

Yes, selects, joins, data integrity should be done on the DB.

But the original poster was talking about having complex _PHP_ stored procedures to do stuff - see the last two paragraphs.

Will that sort of thing work as well on slony etc?

Often decent hardware is a lot more reliable and robust than most of the clustering systems I've encountered. So even though one is doing clustering for performance it's scary to me when it's for the DB - I'd rather have it on one powerful reliable box, not confident of the maturity of the systems out there. Clustering webservers is not a problem.

Re:Application tuning suggestions

[einhverfr]

But the original poster was talking about having complex _PHP_ stored procedures to do stuff - see the last two paragraphs.

Well, I think that is a stupid idea but not for reasons of performance.

MySQL devs are always thinking of one db per app and one app per db. When you do things this way, it doesn't really matter *where* you put the code. But most db's don't evolve to be a single app db. Often you are running multiple apps against that DB after a while.

And in these cases, it is important to cleanly separate what is app specific and what is multi-app. Multi-app functions should be placed in the DB for reasons pertaining to central management. Single-app functions should *not* reside in the DB. Multi-app extratransactional functions (i.e functions outside the db that must be performed after the transaction successfully commits) should be done with a combination architecture (special client, queue table, NOTIFY).

As for if it can be done with Slony, sure. Slony is a master/slave async replication solution. When combined with PgPool, it is possible to route writing operations dynamically to the master. So any functions you want to set up can be used via Slony and PgPool. However, in this case, I think it would be a maintenance nightmare. Indeed if you wanted this sort of architecture, I would suggest a different approach:

1) Set up "middleware" PostgreSQL servers running DBI-Link against a PGPool setup with Slony (for load balancing/replication). Install PL/PHP on them.

2) Set up all your PL/PHP functions on these middleware servers. This way you can separate you DB's, your replication and load balancing, and your web front-end.

You add a little bit of latency, but in the end you gain a whole lot of maintainability and scalability. See, in this case you could use PostgreSQL as a middleware technology....

One more suggestion

[einhverfr]

I always make one important suggestion in these areas:

Use the DB to present and maintain your data.

Put evertything that spans multiple transactions outside the db. For example, don't use your DB to send registration emails out to customers when they sign up on your web site! Use a message table, a client, and notify instead.

Everything else should be put where it is most maintainable. This means that stored procs that expose specific functions to many apps should be put in the db, and the rest shoudl be put in the app.

Absolutely

[Flying pig]

I've seen implementations that do just about everything in stored procedures. Best not to comment on them. Some people will do anything to avoid learning another language.

In fact, though, I prefer to keep database work as portable as possible. The exact thing that db suppliers don't want you to do...

Re:Absolutely

[einhverfr]

In fact, though, I prefer to keep database work as portable as possible.

The most important thing IMO is to keep the interfaces clean. Stored procs wrapped in views accomplish this nicely. It means that you don't have to rewrite your DB *and* your app to move to another DB.

Re:PostgreSQL and C#?

[GooberToo]

Hey, don't get me wrong here. If language support is coming for C#, great! Just the same, which is the original point I was hoping to make, with so many rich choices already available, I find it hard to believe that C# is the only thing holding someone back.

Long story short, PostgreSQL supports the entire gambit of languages (and idioms) already...if C# support is deal breaker, then I suspect something is really going on here.

Re:An honest question. it's not done yet

[rubycodez]

major features of solaris 10 haven't been released yet, and that will make vendors think twice before certifiying products for it

Re:An honest question. it's not done yet

[Anonymous Coward]

"major features of solaris 10 haven't been released yet, and that will make vendors think twice before certifiying products for it"

Major features that haven't been released yet: ZFS, Linux app support.

Major features that have: DTrace, Containers, network performance, small system performance, granular security, signed binaries, unified threading model, fault manager, sevice management facility, new GNOME-based desktop, orders of magnitude better support for x86 systems, support for x64...

1,700+ apps currently committed for support on Solaris 10, so apparently not every vendor is thinking twice, and deciding instead to go for it -- especially since Sun guarantees that their existing apps are compatible with Solaris 10.

So I'm not sure what you mean by "it's not done yet." It's not like there are loose wires dangling from the ceiling or something; it means there's a great operating system you can use today (use since last February, actually), knowing that it's going to get even better as time goes on, without breaking anything you're already doing.

PostgreSQL version for my comments

[alexhmit01]

I am using PostgreSQL 7.4, although one machine in production is still 7.3. We don't have the resources to test and deploy a 8.1 migration at this time, but we are keeping an eye on it.

The 8.x series shows tremendous progress, but the 7.4 branch is stable and not undergoing major changes. When 8.x stabilizes, we'll consider a modernization project.

Alex

Single App Schemas

[alexhmit01]

Generally, keep the data put into schemas for the areas that they function in... instead of 1 DB/app, you have 1 DB, and 1 schema/app. Doesn't seem like much of a difference, but you don't have lots of connections to different DBs, and your app's data can talk to each other WHEN stuff needs to trigger around.

Then, if you are getting hairy, create schemas for app-specific stuff. You can start by wrapping the main calls if needed (a SQL store-procedure that just calls the parent with SECURITY DEFINER) can help keep stuff clean. In this case, you may have app-specific optimizations, but they are all in one place, and talk to the "parent schema" which is still generic.

Latency = lost money... end of story... :)

Alex

Re:Single App Schemas

[einhverfr]

Generally, keep the data put into schemas for the areas that they function in... instead of 1 DB/app, you have 1 DB, and 1 schema/app. Doesn't seem like much of a difference, but you don't have lots of connections to different DBs, and your app's data can talk to each other WHEN stuff needs to trigger around.

But that is not sufficient either. I would suggest one schema per app cluster (a cluster defined as a group of apps using the same data sets).

Often line of business databases evolve first as single app db's and then other apps are added/written in order to further automate things. In these cases, it is pretty wasteful to put every app in its own schema. Instead, you want to have a well defined schema that supports a number of interoperating apps.

In this case, you still want app-specific logic to be in the app, not in the db, while your data-specific logic is in the db. There is often a fine line between the two and some functions can occur either place. But usually when I put functions in the DB they are either wrapped in triggers or views so are hidden behind a table-like interface to keep everything compatible.

Latency = lost money... end of story... :)

Everything Bad = Lost Money. Additional equipment, latency, maintenance overhead, etc. Optimizing for one factor only will probably cost you more than a multifactor optimization.

In the case I was mentioning, the latency will be there, but I think it is unlikely to be significant. Of course if latency is unusually critical in your environment, then you will want to avoid all middleware solutions because of increased latency and use 2-tier apps only. My only point is that if you want to run PostgreSQL as middleware, it makes sense to have separate servers running PostgreSQL as middleware (and yes, *all* middleware adds latency just, you hope, not enough to make a difference). THe main reasons for doing this are scalability (it requires less admin overhead to add new middleware servers in this case than to add new slave replicas to account for load), maintainability, and more. I think it will often save more than it will cost.

Re:An honest question. it's not done yet

[rubycodez]

you must be joking, there's still patches being released to fix major stability issues. And after ZFS and the Linux support proves stable for a few months then I'd say it's close to being "done". Anyone who adopts a version of an operating system that hasn't been released for more than a year is foolish.