Michael Koziarski wrote:
The implementation involves some funky regex's on the sql sent along to
the connection adapter, so I'm going to do some more extensive testing
within my own app before posting to Trac.
I like the idea, however perhaps it's not ambitious enough?
If instead of doing the value interpolation immediately, we could hold
off and pass the full sql string down to the adapter.
["FULL SQL STRING", bunch, of, values]
Agreed.
I've heard from thoughtworks that the performance difference for
oracle is appreciable. It's probably true for other DBs too.
The largest benefit though would be allowing people to insert huge
blobs without a ... 65k sql statement.
And query caching.
To work around lack of bind variables, our Oracle DBA has enabled cursor
sharing, which is an extra pass that Oracle does over the SQL. So it'll take
two separate SQL statements, say
SELECT * FROM post WHERE id = 123;
SELECT * FROM post WHERE id = 456;
which would normally require Oracle to completely parse the SQL, look at the
rights of the connected user, develop an execution plan and execute it,
separately for each query. With the cursor sharing, it converts them into
SELECT * FROM post WHERE id = :SYS_B_0;
which is then bound to the value. Then Oracle gets to leverage the pre-existing
query execution plan. However, having Oracle parse the SQL to determine if the
SQL is similar or not is not ideal.
Here's a good writeup of it, which links to a PDF that describes what Oracle
does.
http://www.rittman.net/archives/2004/06/bjrn_engsig_on_bind_variables.html
Blair
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
