Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!g14g2000cwa.googlegroups.com!not-for-mail From: "Buck Nuggets" Newsgroups: comp.databases.oracle.server,comp.databases.informix,comp.databases.ibm-db2,microsoft.public.sqlserver.server Subject: Re: Database market share 2004 Date: 6 Jun 2005 14:27:21 -0700 Organization: http://groups.google.com Lines: 52 Message-ID: <1118093241.682743.285140@g14g2000cwa.googlegroups.com> References: <3g0mn8F9vl97U1@individual.net> <1117618673.466094.67890@f14g2000cwb.googlegroups.com> <1117658911.227912.324180@z14g2000cwz.googlegroups.com> <1117708330.639768.121670@g47g2000cwa.googlegroups.com> <429f0643$0$17153$e4fe514c@news.xs4all.nl> <1117719697.270423@yasure> <42a00a2f$0$29637$e4fe514c@news.xs4all.nl> NNTP-Posting-Host: 69.171.226.85 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1118093250 30338 127.0.0.1 (6 Jun 2005 21:27:30 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 6 Jun 2005 21:27:30 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g14g2000cwa.googlegroups.com; posting-host=69.171.226.85; posting-account=fnmwVw0AAAArJLlANJh4uzXA98FmHhoC Xref: dp-news.maxwell.syr.edu comp.databases.oracle.server:244382 comp.databases.informix:117873 comp.databases.ibm-db2:88388 microsoft.public.sqlserver.server:333096 Jurgen Haan wrote: > DA Morgan wrote: > > Jurgen Haan wrote: > > > There is another important reason too: Instrumentation. If they are > > slow diagnosing why is a question of making guesses. That may be a > > reasonable approach when supporting a small non-commercial web site. > > It is a non-starter when talking terabytes and a requirement for 7x24. > > And then there's that little problem with government requirements > > around audits. They just aren't ready for prime-time. > > 24x7 is actually no problem with OSS db's like Postgres. > At the company where I work we have a DB2 DB and a Postgres DB running. > Neither of them have to be taken down during maintenance. Next week I get to swap out two storage arrays on a 500-gbyte db2 udb database server: the new arrays are larger and faster. Anyhow, one nice feature about db2 is that I can add the new arrays & remove the old ones in a relatively simple operation in which the database handles rebalancing all data automatically, and everything is online the entire time. Didn't think postgresql was up to that yet. > What's a big problem with postgres (and actually one of the main reasons > why we don't use it for our sensitive information) and that's that > postgres is extremely unrelyable in high TPS situations. > Scalability with OSS databases just plain sucks (if any). Although I really like postgesql, the biggest reasons not to use it in production for us are: 1. If it can't do everything then we need db2 as well. Standardizing on db2 is simpler than maintaining a mix of skills, procedures, products, etc. 2. postgresql doesn't support query parallelism or partitioning. This means that db2 table scans run about 40x the speed of postgresql table scans (assuming a 4-way server and typical partitioning benefits). 3. db2 is pretty inexpensive in its small-server editions (workgroup, express, etc). So the savings of going with postgresql is more than wiped out by the additional hardware requirements. > But still I think OSS databases are to be reconed with. > > It's the same as the early 90s, Linux, what a cute little project, but > it surely will never be of any importance. Now, just take a look a the > linux population among Internet web servers. Yep, postgresql is on track to be a cool DBMS. buck