Regardless of how the query was handled, the fact is that it involved three tables, each with a million+. RDBMSes that can handle huge single tables can sometimes choke on queries involving joins of many smallers tables.

Did they include any range joins on non-index columns ?

No, because I could avoid them based on application requirements. I actually avoided every single non-index join I could. I did have to do non-index range checks on date fields, but that's par for the course.

Can make mistakes - Only perl can parse Perl, which includes non-Perl stuff

You're missing the point - source filters can break on legal syntax, leading to very difficult-to-diagnose errors. Filtering Perl syntax is harder than most, but even the simplistic SQL syntax can be hard at times.

Hmm, since I never mentioned Oracle in my post, I'm not certain what question I'm being asked to elaborate on?

DB2, Sybase, whatever. The point is that each RDBMS has its strengths and its weaknesses. I will be the first to point out that MySQL will not have production-ready triggers or updateable views for at least 6 months to a year. And, even then, I wouldn't use it. Yet, MySQL is enterprise-ready and is faster under many circumstances than every other RDBMS (commercial or OSS) out there, including Oracle, Sybase, and DB2. Those circumstances can include very complex queries against tables with millions of rows in them.

Can't answer that one, except to say I don't see anything in SQL::Preproc that persists anything the application can't override.

That's not the problem. Some source filters use INIT and CHECK blocks to do their work. Others, like Filter::Simple (which is what SQL::Preproc uses) don't. BEGIN, INIT, and CHECK blocks don't always behave as expected in persistent environments.

I've seen many instances where separation/encapsulation led to throwing an object wrapper around a cursor on a large table, . . .

q.v. OO concepts and relational databases for my thoughts on that.