Re: [pgsql-advocacy] Oracle buys Innobase

Поиск
Список
Период
Сортировка
От Chris Browne
Тема Re: [pgsql-advocacy] Oracle buys Innobase
Дата
Msg-id 60psq3g90u.fsf@dba2.int.libertyrms.com
обсуждение исходный текст
Ответ на Re: [pgsql-advocacy] Oracle buys Innobase  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-general
tgl@sss.pgh.pa.us (Tom Lane) writes:

> Chris Browne <cbbrowne@acm.org> writes:
>> tgl@sss.pgh.pa.us (Tom Lane) writes:
>>> I've been trying to figure out what it is that Oracle gets out of
>>> this, assuming that they don't see MySQL as a serious threat to
>>> their core business.
>
>> [ snip ]
>
>> Of course, if the "ability to support R/3" requires InnoDB stuff, then
>> this means Oracle just did a nice job of cutting off this strategy...
>
> Ah-hah.  *Now* it's all clear: an alternative to Oracle for SAP would
> definitely be a strong threat to Oracle's bottom line.  I think we just
> found the real motivation.
>
> (BTW, has anyone looked lately to see how far away Postgres is from
> being able to run SAP?)

I'd think that the main issue is that of attracting interest from SAP
AG to do a port.

They don't require triggers, RI, stored procedures, nor, if I recall,
views.

Sybase was long NOT supportable due to it not having row locks, but
rather only page locks.  That drove functionality added to Microsoft
SQL Server back in the late '90s.

It's _possible_ that MVCC could cause some heartburn, though since
Oracle and DB2 both have added forms of this, I kind of doubt it.

I don't expect that Postgres is missing anything of importance aside
from there being a "champion" with budgetary discretion for the $8M
task of preparing a port.  R/3 has fairly separate "kernels" for each
DBMS that it supports, and that's not a small thing.

It's _not_ like in the late '90s where internal developers had
"skunkworks" ports of Oracle/Informix/DB2 to Linux where they were
able to report "Oh, we compiled it one weekend and it found that it
just simply works."  Porting the R/3 kernel to another DBMS would
involve things akin to:
 - Coding an internal layer that knows to talk to libpq
 - Knowing the different ways of handling R/3 weirdities like cluster
   tables (where I'd bet money that DEFINE TYPE would make life easier
   in a PostgreSQL port...)
 - Awareness of the variations in locking semantics and such

The kernel is a real heavyweight, so a port would require quite a lot
of effort.
--
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://cbbrowne.com/info/linuxdistributions.html
"The  test of a  principle  is whether it  applies  even to people you
don't like." -- Henry Spencer

В списке pgsql-general по дате отправления:

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: Re: backends and pg_stat_activity
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Planner regression in 8.0.x ?