Thread: drop-in-ability (was: RE: Re: [PATCHES] Select parser a t runtime )

drop-in-ability (was: RE: Re: [PATCHES] Select parser a t runtime )

From
Alex Avriette
Date:
I sent the list a message a little while ago about what I do with postgres.
I thought, after all this discussion, that it might be important to send a
further message to the list indicating why I chose not to use Oracle.

I'm going to go out on a limb and say that I have one of the largest
postgres databases in the world. At our site, we have quite a few oracle
instances and something like 27 schemas (and, I'm afraid to report, a few
Access as well). Our PG database dwarfs all the other databases combined.

I chose postgres not because of any cost issue at all. The project that I am
working on here is accustomed to spending $25,000 in a given week for new
hardware, we bring on consultants as we need them et cetera. To me, what
made postgres attractive was how simple it was to install and configure.
Furthermore, I have had discussions with our oracle DBA's. When I mentioned
I thought our number of rows could reach into the tens of millions, and the
eventual storage estimate is something on the order of several terabytes, he
told me I would need to hire on 2-3 fulltime DBA's if I wanted to use
Oracle.

My feeling on whether postgres is a "drop-in" replacement for Oracle is
similarly simple. Any sufficiently competent programmer can make
database-independant code. Up to this point, I have been working hard to
make sure that, should higher management decide to use Oracle, I can use
pg_dump and actually just move on over to Oracle. I would have chosen a
similar approach if I had started with Oracle. Perhaps it is my background
as a Perl programmer (it is the DataBase Independant driver, afterall), or
perhaps it is my fear of change. But if you guys are concerned that one
database is not a drop-in replacement for another, you are paying your
programmers too much. I think perhaps it is the "Oracle Mentality" (or dare
I say, Microsoft Mentality) to not worry about portability and compatibility
that breeds this kind of programming and production. It is very much
against, however, the opensource mentality.

Dont beat yourself up, guys, over making postgres a drop-in replacement for
Oracle. The people that would benefit from actually "dropping in" postgres
into an Oracle install will have already eased the burden on themselves by
being responsible in their database construction and programming. I haven't
even been able to convince our Oracle guys that Postgres is actually a "real
database" (its free?!! how can it be free?!). They would never, (ever!)
consider dropping in postgres. If you're intent on taking "customers" from
Oracle, catch them where youll be able to convert them -- before Oracle is
even installed.

alex


Re: drop-in-ability (was: RE: Re: [PATCHES] Select parser a t runtime )

From
Ian Lance Taylor
Date:
Alex Avriette <a_avriette@acs.org> writes:

> Dont beat yourself up, guys, over making postgres a drop-in replacement for
> Oracle. The people that would benefit from actually "dropping in" postgres
> into an Oracle install will have already eased the burden on themselves by
> being responsible in their database construction and programming. I haven't
> even been able to convince our Oracle guys that Postgres is actually a "real
> database" (its free?!! how can it be free?!). They would never, (ever!)
> consider dropping in postgres. If you're intent on taking "customers" from
> Oracle, catch them where youll be able to convert them -- before Oracle is
> even installed.

In principle, I agree with you.  However, my company (Zembu) has a
business need for better Oracle compatibility, based on real customer
need.

Zembu doesn't don't have a need to make Postgres a drop-in replacement
for Oracle; that is a nearly impossible task in any case, because
Oracle DBAs don't know how to manage Postgres, and most don't want to
learn.  Zembu does have a need to permit applications to speak to both
Oracle and Postgres.

Just to be clear, I am not on the Postgres development team.  I'm
talking about work which is important for Zembu, and which I believe
can be quite helpful to Postgres in general.  I'm trying to structure
the work so that even if accepted it would not take too many cycles
away from core Postgres development.

Ian