Re: MS interview

> > >
> > > Near the end he gets specifically asked about "Red Hat Database" as a
> > > competitive threat, and he responds that he doesn't think anyone can match
> > > their "investment" of "800 professionals" to work on SQL Server.
> > >
> > > Now I'm sure he didn't mean it to sound this way, but what I conclude from
> > > that is that you fellows are all an order of magnitude or two more
> > > productive than anyone at Microsoft :-).

There is a basic reality to IT purchasing, Microsoft, Oracle, DB2, and to a
lesser extent informix, and Sybase have an amount of "clout" that PostgreSQL
does not. This clout isn't based on functionality so much as a big company that
you can "sue." Nobody can sue these companies, of course, because the license
agreements indicate that you can not. It is also based on support, "who will
support you when you have trouble?" This is a quaint notion, but Oracle support
is very expensive.

The war for PostgreSQL, IMHO, is the same war that Linux fought and won over
the last couple years, perception. Three years ago, it would have been risky
for an IT guy to suggest, openly, that the infrastructure rely upon Linux.
Today, while it isn't a forgone conclusion, you can raise that point in a
meeting and not be ridiculed. People would consider it.

I use PostgreSQL all the time, I think it is a great system, and you guys do
great work. I am currently using Postgres for data analysis and as the
presentation system for a text search and music ID engine. However, I would
hesitate to move it to replace an Oracle or a DB2 because if Oracle or DB2
fail, everyone gets to blame the vendor, if PostgreSQL fails, everyone gets to
blame me.

IMHO, if The PostgreSQL team is serious about moving PostgreSQL out of the
niche tool market and into the general SQL market place along side of Oracle,
DB2, and MSSQL there is a lot of work to be done.

Think about a website, where you have session management. 10,000 users online
at one time each doing something that affects their account once a minute. That
is about 166 updates a second on a session table. How often would you need to
run vacuum for these operations to remain efficient? I submit that PostgreSQL
will never be able to perform well in this environment as long as updates
affect performance prior to a vacuum.

Of late the 32 bit OID issue. If you have an OID wrap around, you have some
probability that two records in a table could have the same OID. The
probability, of course, is based on the number of tables and the distribution
of activity on the tables, but it is likely to happen. Is this a problem?

Then there is data security. Oracle is very good here. One can restore from
their last backup, and using the REDO logs, bring the database to the point
just before the crash. When I've had to answer this in meetings, I have to
shrug and concede that point. (I have actually seen this work and it is cool.)

Then there is the laundry list of functionality, queries across databases,
functions like cube and rollup, etc.

Believe me, I'm not knocking PostgreSQL, but if I am to recommend PostgreSQL in
place of an Oracle or a DB2 or an MSSQL, it needs these things, even if they
are never used, I have to convince people that PostgreSQL is "safe" to deploy.