On Wed, 2007-05-16 at 09:37 -0400, Brian Hurt wrote:
> I have never understood the purpose of having more than one "backend" to
> the database. As near as I can figure, it's only purpose is to allow
> people to pick the wrong one.
>
PostgreSQL offers choice as well: there are Btree, GiST, and GIN index
access methods, all in common use. There are many plans available for
the same or similar operations: sort, index scan, bitmap index scan,
hash join, nested loop, merge join, hash aggregate, etc.
In PostgreSQL, changing access methods is as simple as creating the
right indexes and constraints, and letting the planner choose the new
plan when it happens to be the lowest cost.
The only thing that's the same in every case is the heap itself, and
that will change when HOT is implemented. Storage can also be changed by
placing objects into tablespaces residing on different underlying
storage systems. Or, you can use views and rules to present one relation
to applications while storing the underlying data in several tables (or
present one physical table as many logical tables).
What MySQL _really_ offers is a choice of implementations that affect
(read: compromise) the high-level semantics and break user queries.
In MySQL, changing the "storage engine" can break user queries and
always requires a full data migration to the new format.
I agree 100% that asking the MySQL user to make choices that affect both
the semantics of user queries and the long-term performance of the
application at the time the table is created is too much of a burden. It
works against the benefits that relational databases provide: that you
can change and scale up as requirements change without constant -- and
error prone -- data migrations.
Regards,
Jeff Davis
