Re: Information about storge engine in PostgreSQL

On 10/21/2004 10:27 AM, nd02tsk(at)student(dot)hig(dot)se wrote:

> Hello
>
> MySQL has information about several storage engines. MEMORY to handle
> temporary tables, InnoDB to handle transactions and which also can split
> its table data over several files/partitions. Splitting of storage is
> something which according to the following article, PostgreSQL does not
> support:

For a long time the MySQL documentation was stating that foreign keys
are mainly for documentation purposes and explained why you really
didn't want them and why it was so much better that MySQL swallowed
their syntax silently without any effect. Similarly dangerous opinions
where documented about transactions and ACID features.

Then the InnoDB table handler was added to MySQL and with the new
features, namely transactions and referential integrity, the documented
opinion about these features was changed. But since every other database
had these features for long already, all that was left was now the
capability of having different storage engines, and it became the new
advantage feature to point out.

Right now on their boiler plate is another buzzword compliant table
handler, the NDB cluster storage engine. And while a lot of people are
getting all excited about it, all I really see so far is yet another
table handler that does not provide foreign keys, that does not
integrate with the existing transaction systems ACID properties, and
that has outrageous network and memory requirements. Especially worried
am I about the fact that the responsibility for referential integrity,
that was lifted from the developers shoulders with the InnoDB tables, is
now dropped twice as heavy back into his laps. I don't think that Web
developers who had problems getting integrity constraints implemented in
the application before InnoDB will do this much better in a concurrent
multimaster cluster environment. But I am sure enough PHB's who, free
from every knowledge obstacles, fully believe in marketing speech will
force their developers into that nightmare.

None of all these advanced storage engines was developed by MySQL. They
all got purchased and turned into table handlers. The multiple storage
engine capability of MySQL is the technical base for stapling together
those features, MySQL isn't able to build into the existing system and
has to buy somewhere else.

The PostgreSQL philosophy is a little different. That is why we have
only one, tightly integrated and not very easy to replace storage engine.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #