Clarify the wording of the Rails/PluckInWhere cop

[padarom]

Clarifies the existing wording to be easier to understand and adds an additional paragraph about possible performance implications of this cop.

These implications have been mentioned before in #310 (comment), but weren't explicitly mentioned in the cop's documentation.

---

The linked issue mentions MySQL and I have found the same issue multiple times showing up in MySQL on Stack Overflow, but I ran into it on PostgreSQL today. The query was something along the lines of this, albeit a bit more complicated:

query = %{
  (type = ? AND model_id IN (?)) OR
  (type = ? AND model_id IN (?))
}

Foo.where(query, 'bar', bar_ids,
                 'baz', Baz.where(condition: true).pluck(:id))

The pluck in the last line was replaced with a select, which caused the Baz query to be ran as a subquery instead of eagerly. This resulted in major database load, as Foos table in this case is around 200GB in size and the query was now using sequential scanning, rather than index scanning.

Some research led us to find the related description in the PostgreSQL documentation:

The right-hand side is a parenthesized subquery, which must return exactly one column. The left-hand expression is evaluated and compared to each row of the subquery result.

This means that queries such as SELECT * FROM foo WHERE model_id IN (subquery) use sequential scanning to match against the model_id, rather than index scanning. Eager loading in this case was much faster, as it allowed an index lookup against the static list provided to the query.

Note to future readers: Rather than using column IN (subquery) you can use column = ANY(ARRAY(subquery)), which causes the subquery to be executed first and allows for an index scan.

---

Before submitting the PR make sure the following are checked:

• The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• Wrote good commit messages.
• Commit message starts with [Fix #issue-number] (if the related issue exists).
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.
• If this is a new cop, consider making a corresponding update to the Rails Style Guide.

[koic]

Thanks!