Luke Welling asked:
Specifically, do we use MySQL specific syntax that is
more efficient (but
breaks elsewhere) or do we attempt to write lowest common denominator SQL
that will run more places, but not run as efficiently on our primary target?
Neither: we use the already-existing methods, and have those examine
db-specific attributes to modify their behavior. The SQL itself stays
pretty basic: I don't know that I've ever seen SQL (in core anyway),
that varied enough between backends to require a differentiation. If
we do encounter such a thing, it's probably best to pick the simplest
variation (if possible), or the MySQL one (if not), and have attributes
determine which variant is used (e.g. if ( $dbr->left_join_expensive() )
Matt Flaschen wrote:
However, part of the optimization is choosing indices,
which as you
noted is db-specific (part of tables.sql)
Not sure what you mean - index hints? Yeah, that could be a little tricky,
but luckily the Postgres part, at any rate, doesn't have to worry about
those (as our planner is smart enough to pick the best index itself ;).
I can't think of a clean way to abstract that anyway, as just needing
an index hint for MySQL does mean the same is needed on Oracle, and
vice-versa. So you'd already have a very database specific argument
for each query anyway, such that you would never have to worry if other
dbs had the same index.
--
Greg Sabino Mullane greg(a)endpoint.com
End Point Corporation
PGP Key: 0x14964AC8