On Apr 17, 2008, at 9:08 AM, Mark Waser wrote:
Yes, the newest versions of PostgeSQL could spank SQL Server 2000
after it was several years old. One tremendous advantage of
PostgreSQL is it's very short development cycle.
Actually, this was a fundamental and known weakness in the SQL Server
2000 transactional model, being more like DB2 than Oracle. Because
PostgreSQL has used the same kind of model as Oracle -- and for a very
long time -- it has always been relatively strong at OLTP throughput.
Until SQL Server 2005, the Microsoft offering was never really
competitive. It had little to do with development timelines. On the
other hand, PostgreSQL was a bit of a dog at OLAP until relatively
recently.
You imply that the performance is due to some kind of linear
development path, but in fact SQL Server 2005 changed its internal
model to be like Oracle and PostgreSQL so that it could be competitive
at OLTP. It is a matter of algorithm selection and tradeoffs, not
engineering effort. SQL Server (until two years ago) has always had
relatively poor lock concurrency, but gave very good baseline OLAP
performance as a consequence of that decision. The reality is that it
is much easier to make the Oracle/Postgres model perform
satisfactorily at OLAP than to make the old SQL Server model perform
satisfactorily at OLTP.
-- in 2005 they switched to a transaction model more like
PostgreSQL and Oracle and gained some parity. SQL Server still
does not really distribute all that easily, unlike Oracle or
PostgreSQL.
Have you ever worked with an Oracle distributed database? Oracle
does not distribute well.
I've worked with very large databases on several major platforms,
including Oracle and SQL Server in many different guises. Oracle's
parallel implementation may not distribute that well, but that is
because traditional transactional semantics are *theoretically
incapable* of distributing well. To the extent it is possible at all,
Oracle does a very good job at making it work.
There are new transactional architectures in academia that should work
better in a modern distributed environment than any of the current
commercial adaptations of classical architectures to distributed
environments.
Oracle only scales well when you know how to properly use it. In
most installations that I've seen, Oracle underperforms even SQL
Server 2000 because the DBA didn't do the necessary to make it
perform optimally (because Oracle is *NOT* average person
friendly). I've made *a lot* of money optimizing people's Oracle
installations that I shouldn't have been able to make if Oracle
could get out of it's own way.
No argument here, one of the major problems of Oracle is that it is
bloody impossible to use well without a full-time staff. I spent many
years solving scaling problems on extremely large Oracle systems. The
insidiousness of PostgreSQL in the market is that it is very Oracle-
like at a high-level but *massively* simpler and easier to use and
administer while still delivering much of the performance and a
significant subset of the features of Oracle. SQL Server has done
well against Oracle for similar reasons.
The main problem with SQL Server these days is that it does not run on
Unix. Most of the major historical suckiness does not apply to the
current version.
Making deep and very flexible customization a safe core feature
was a design decision tradeoff in PostgreSQL that is somewhat
unique to it. You can do a lot of really cool software
implementation tricks with it that Oracle and SQL Server do not do.
Yes. The biggest problems with PostgreSQL are that it doesn't have
a Microsoft compatibility mode and it isn't clear to corporations
where you can get *absolutely guaranteed* support.
Sun Microsystems not only officially supports it, they do a lot of
development on it, as does Fujitsu in Asia, Red Hat and a few other
large companies that are heavily invested in it. A significant
portion of the main PostgreSQL developers do it as their official
corporate job.
PostgreSQL is very broadly ANSI compatible (including a lot of
ancillary database standards surrounding SQL), and to the extent it
has a "flavor" it clearly borrows from Oracle rather than SQL Server.
SQL Server has a lot of bits that do not conform to standards that
everyone else supports. From a historical perspective, PostgreSQL
shares a transaction model with Oracle, started on Unix, and has been
around since a time when SQL Server was not something you would want
to emulate. PostgreSQL has matured to the point where it mostly
follows standards to the extent possible but has enough unique
features and capabilities that it has started to become a flavor of
its own.
If you could swap out an MS-SQL server *immediately* for a
PostgreSQL server simply by copy the data and rebinding a WINS name
or an IP address, I would be in hog heaven even if support wasn't
absolutely guaranteed since I could always switch back. Given that
there's a huge transition cost (changing scripts, procedures, etc.),
I can't get *ANY* agreement for the thought of switching (and I'm
sure that there are *MANY* more in my circumstances).
The only corporate database that relatively easily ports back and
forth with PostgreSQL is Oracle. Nonetheless, a number of people have
ported applications to PostgreSQL from MS-SQL with good results;
questions about porting nuances come up regularly on the PostgreSQL
mailing lists.
Beyond your basic ANSI compliance, database portability only sort of
exists. Inevitably people use non-standard platform features that
expose the specific capabilities of the engine being used to maximize
performance. As a practical matter, you pick a database platform and
stick with it as long as is reasonably possible.
J. Andrew Rogers
-------------------------------------------
agi
Archives: http://www.listbox.com/member/archive/303/=now
RSS Feed: http://www.listbox.com/member/archive/rss/303/
Modify Your Subscription:
http://www.listbox.com/member/?member_id=8660244&id_secret=101455710-f059c4
Powered by Listbox: http://www.listbox.com
