2017-07-09 13:41:28 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2017-10-21 09:17:03 -04:00
|
|
|
require "active_record/explain_registry"
|
2011-12-15 15:07:41 -05:00
|
|
|
|
2011-12-02 07:32:18 -05:00
|
|
|
module ActiveRecord
|
2011-12-02 14:16:07 -05:00
|
|
|
module Explain
|
2013-04-16 16:46:55 -04:00
|
|
|
# Executes the block with the collect flag enabled. Queries are collected
|
|
|
|
# asynchronously by the subscriber and returned.
|
2011-12-16 15:12:05 -05:00
|
|
|
def collecting_queries_for_explain # :nodoc:
|
2013-04-16 16:46:55 -04:00
|
|
|
ExplainRegistry.collect = true
|
2013-03-05 10:35:55 -05:00
|
|
|
yield
|
2013-04-16 16:46:55 -04:00
|
|
|
ExplainRegistry.queries
|
2011-12-16 15:12:05 -05:00
|
|
|
ensure
|
2013-04-16 16:46:55 -04:00
|
|
|
ExplainRegistry.reset
|
2011-12-16 15:12:05 -05:00
|
|
|
end
|
2011-12-15 15:07:41 -05:00
|
|
|
|
2011-12-16 15:12:05 -05:00
|
|
|
# Makes the adapter execute EXPLAIN for the tuples of queries and bindings.
|
|
|
|
# Returns a formatted string ready to be logged.
|
|
|
|
def exec_explain(queries) # :nodoc:
|
2016-07-18 20:43:38 -04:00
|
|
|
str = queries.map do |sql, binds|
|
2018-05-17 04:32:27 -04:00
|
|
|
msg = +"EXPLAIN for: #{sql}"
|
2016-07-18 20:43:38 -04:00
|
|
|
unless binds.empty?
|
|
|
|
msg << " "
|
|
|
|
msg << binds.map { |attr| render_bind(attr) }.inspect
|
|
|
|
end
|
|
|
|
msg << "\n"
|
|
|
|
msg << connection.explain(sql, binds)
|
2011-12-16 15:12:05 -05:00
|
|
|
end.join("\n")
|
2012-05-31 03:58:17 -04:00
|
|
|
|
2014-07-19 03:20:41 -04:00
|
|
|
# Overriding inspect to be more human readable, especially in the console.
|
2012-05-31 03:58:17 -04:00
|
|
|
def str.inspect
|
|
|
|
self
|
|
|
|
end
|
2013-04-16 16:46:55 -04:00
|
|
|
|
2012-05-31 03:58:17 -04:00
|
|
|
str
|
2011-12-16 15:12:05 -05:00
|
|
|
end
|
2016-07-18 20:43:38 -04:00
|
|
|
|
|
|
|
private
|
|
|
|
def render_bind(attr)
|
Should not substitute binds when `prepared_statements: true`
Before IN clause optimization 70ddb8a, Active Record had generated an
SQL with binds when `prepared_statements: true`:
```ruby
# prepared_statements: true
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id` IN (?, ?, ?)
#
# prepared_statements: false
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id` IN (1, 2, 3)
#
Author.where(id: [1, 2, 3]).to_a
```
But now, binds in IN clause is substituted regardless of whether
`prepared_statements: true` or not:
```ruby
# prepared_statements: true
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id`IN (1,2,3)
#
# prepared_statements: false
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id`IN (1,2,3)
#
Author.where(id: [1, 2, 3]).to_a
```
I suppose that is considered as a regression for the context:
> While I would prefer that we fix/avoid the too-many-parameters
problem, but I don't like the idea of globally ditching bind params for
this edge case... we're getting to the point where I'd almost consider
anything that doesn't use a bind to be a bug.
https://github.com/rails/rails/pull/33844#issuecomment-421000003
This makes binds consider whether `prepared_statements: true` or not
(i.e. restore the original behavior as before), but still gain that
optimization when need the substitute binds (`prepared_statements: false`,
`relation.to_sql`). Even when `prepared_statements: true`, it still
much faster than before by optimized (bind node less) binds generation.
```ruby
class Post < ActiveRecord::Base
end
ids = (1..1000).each.map do |n|
Post.create!.id
end
puts "prepared_statements: #{Post.connection.prepared_statements.inspect}"
Benchmark.ips do |x|
x.report("where with ids") do
Post.where(id: ids).to_a
end
end
```
* Before (200058b0113efc7158432484d71c1a4f1484a4a1)
`prepared_statements: true`:
```
Warming up --------------------------------------
where with ids 6.000 i/100ms
Calculating -------------------------------------
where with ids 63.806 (± 7.8%) i/s - 318.000 in 5.015903s
```
`prepared_statements: false`:
```
Warming up --------------------------------------
where with ids 7.000 i/100ms
Calculating -------------------------------------
where with ids 73.550 (± 8.2%) i/s - 371.000 in 5.085672s
```
* Now with this change
`prepared_statements: true`:
```
Warming up --------------------------------------
where with ids 9.000 i/100ms
Calculating -------------------------------------
where with ids 91.992 (± 7.6%) i/s - 459.000 in 5.020817s
```
`prepared_statements: false`:
```
Warming up --------------------------------------
where with ids 10.000 i/100ms
Calculating -------------------------------------
where with ids 104.335 (± 8.6%) i/s - 520.000 in 5.026425s
```
2020-05-10 03:09:41 -04:00
|
|
|
if ActiveModel::Attribute === attr
|
|
|
|
value = if attr.type.binary? && attr.value
|
|
|
|
"<#{attr.value_for_database.to_s.bytesize} bytes of binary data>"
|
|
|
|
else
|
|
|
|
connection.type_cast(attr.value_for_database)
|
|
|
|
end
|
2016-07-18 20:43:38 -04:00
|
|
|
else
|
Should not substitute binds when `prepared_statements: true`
Before IN clause optimization 70ddb8a, Active Record had generated an
SQL with binds when `prepared_statements: true`:
```ruby
# prepared_statements: true
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id` IN (?, ?, ?)
#
# prepared_statements: false
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id` IN (1, 2, 3)
#
Author.where(id: [1, 2, 3]).to_a
```
But now, binds in IN clause is substituted regardless of whether
`prepared_statements: true` or not:
```ruby
# prepared_statements: true
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id`IN (1,2,3)
#
# prepared_statements: false
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id`IN (1,2,3)
#
Author.where(id: [1, 2, 3]).to_a
```
I suppose that is considered as a regression for the context:
> While I would prefer that we fix/avoid the too-many-parameters
problem, but I don't like the idea of globally ditching bind params for
this edge case... we're getting to the point where I'd almost consider
anything that doesn't use a bind to be a bug.
https://github.com/rails/rails/pull/33844#issuecomment-421000003
This makes binds consider whether `prepared_statements: true` or not
(i.e. restore the original behavior as before), but still gain that
optimization when need the substitute binds (`prepared_statements: false`,
`relation.to_sql`). Even when `prepared_statements: true`, it still
much faster than before by optimized (bind node less) binds generation.
```ruby
class Post < ActiveRecord::Base
end
ids = (1..1000).each.map do |n|
Post.create!.id
end
puts "prepared_statements: #{Post.connection.prepared_statements.inspect}"
Benchmark.ips do |x|
x.report("where with ids") do
Post.where(id: ids).to_a
end
end
```
* Before (200058b0113efc7158432484d71c1a4f1484a4a1)
`prepared_statements: true`:
```
Warming up --------------------------------------
where with ids 6.000 i/100ms
Calculating -------------------------------------
where with ids 63.806 (± 7.8%) i/s - 318.000 in 5.015903s
```
`prepared_statements: false`:
```
Warming up --------------------------------------
where with ids 7.000 i/100ms
Calculating -------------------------------------
where with ids 73.550 (± 8.2%) i/s - 371.000 in 5.085672s
```
* Now with this change
`prepared_statements: true`:
```
Warming up --------------------------------------
where with ids 9.000 i/100ms
Calculating -------------------------------------
where with ids 91.992 (± 7.6%) i/s - 459.000 in 5.020817s
```
`prepared_statements: false`:
```
Warming up --------------------------------------
where with ids 10.000 i/100ms
Calculating -------------------------------------
where with ids 104.335 (± 8.6%) i/s - 520.000 in 5.026425s
```
2020-05-10 03:09:41 -04:00
|
|
|
value = connection.type_cast(attr)
|
|
|
|
attr = nil
|
2016-07-18 20:43:38 -04:00
|
|
|
end
|
|
|
|
|
Should not substitute binds when `prepared_statements: true`
Before IN clause optimization 70ddb8a, Active Record had generated an
SQL with binds when `prepared_statements: true`:
```ruby
# prepared_statements: true
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id` IN (?, ?, ?)
#
# prepared_statements: false
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id` IN (1, 2, 3)
#
Author.where(id: [1, 2, 3]).to_a
```
But now, binds in IN clause is substituted regardless of whether
`prepared_statements: true` or not:
```ruby
# prepared_statements: true
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id`IN (1,2,3)
#
# prepared_statements: false
#
# SELECT `authors`.* FROM `authors` WHERE `authors`.`id`IN (1,2,3)
#
Author.where(id: [1, 2, 3]).to_a
```
I suppose that is considered as a regression for the context:
> While I would prefer that we fix/avoid the too-many-parameters
problem, but I don't like the idea of globally ditching bind params for
this edge case... we're getting to the point where I'd almost consider
anything that doesn't use a bind to be a bug.
https://github.com/rails/rails/pull/33844#issuecomment-421000003
This makes binds consider whether `prepared_statements: true` or not
(i.e. restore the original behavior as before), but still gain that
optimization when need the substitute binds (`prepared_statements: false`,
`relation.to_sql`). Even when `prepared_statements: true`, it still
much faster than before by optimized (bind node less) binds generation.
```ruby
class Post < ActiveRecord::Base
end
ids = (1..1000).each.map do |n|
Post.create!.id
end
puts "prepared_statements: #{Post.connection.prepared_statements.inspect}"
Benchmark.ips do |x|
x.report("where with ids") do
Post.where(id: ids).to_a
end
end
```
* Before (200058b0113efc7158432484d71c1a4f1484a4a1)
`prepared_statements: true`:
```
Warming up --------------------------------------
where with ids 6.000 i/100ms
Calculating -------------------------------------
where with ids 63.806 (± 7.8%) i/s - 318.000 in 5.015903s
```
`prepared_statements: false`:
```
Warming up --------------------------------------
where with ids 7.000 i/100ms
Calculating -------------------------------------
where with ids 73.550 (± 8.2%) i/s - 371.000 in 5.085672s
```
* Now with this change
`prepared_statements: true`:
```
Warming up --------------------------------------
where with ids 9.000 i/100ms
Calculating -------------------------------------
where with ids 91.992 (± 7.6%) i/s - 459.000 in 5.020817s
```
`prepared_statements: false`:
```
Warming up --------------------------------------
where with ids 10.000 i/100ms
Calculating -------------------------------------
where with ids 104.335 (± 8.6%) i/s - 520.000 in 5.026425s
```
2020-05-10 03:09:41 -04:00
|
|
|
[attr&.name, value]
|
2016-07-18 20:43:38 -04:00
|
|
|
end
|
2011-12-02 07:32:18 -05:00
|
|
|
end
|
|
|
|
end
|