Re: Information about storge engine in PostgreSQL - Mailing list pgsql-general

I really appreciate these type of high-quality anwsers, thank you.

Tim

> On 10/21/2004 10:27 AM, nd02tsk@student.hig.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@Yahoo.com #
>