# High Performance PostgreSQL for Rails: Explanation regarding the use of includes with a limit (Page 124)

**URL:** <https://forum.devtalk.com/t/high-performance-postgresql-for-rails-explanation-regarding-the-use-of-includes-with-a-limit-page-124/161023>\
**Category:** PragProg Customers\
**Tags:** book-high-performance-postgresql-for-rails, suggestion\
**Created:** [5 July 2024 12:43 UTC](https://forum.devtalk.com/t/high-performance-postgresql-for-rails-explanation-regarding-the-use-of-includes-with-a-limit-page-124/161023 "2024-07-05T12:43:30Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![viktorianer](https://forum.devtalk.com/user_avatar/forum.devtalk.com/viktorianer/32/6178_2.png) [@viktorianer](https://forum.devtalk.com/u/viktorianer)\
**Post date:** [5 July 2024 12:43 UTC](https://forum.devtalk.com/t/high-performance-postgresql-for-rails-explanation-regarding-the-use-of-includes-with-a-limit-page-124/161023/1 "2024-07-05T12:43:30Z")

</div>

Dear Andrew, @andatki

I found the explanation regarding the use of `.includes()` with a `limit` in the context of vehicle reservations to be quite insightful. However, I believe the discussion on performance implications could benefit from further clarification, particularly regarding the difference in behavior with and without a `limit`.

Here’s a suggested rewrite to enhance clarity:

* * *

When using `.includes()` to load vehicle reservations, the query is split into two parts. First, a query retrieves a limited number of vehicles (e.g., 2 vehicles). Then, another query fetches the associated reservations for these vehicles using an `IN` clause with the `vehicle_id`s of the retrieved vehicles. Keep in mind that if the `IN` clause contains too many values, it can lead to performance issues.

### Performance Implications

- **Without limit:** If there are many vehicles, the `IN` clause can become very large, which may degrade performance.
- **With limit:** The `IN` clause remains small, improving performance for the secondary query.

* * *

Additionally, this explanation can move before `LEFT OUTER JOIN` part, in order to avoid a context switch.

I hope this suggestion helps make the performance implications clearer for the readers.

Best regards,

Viktor

---

<div class="post-metadata">

**Author:** ![andatki](https://forum.devtalk.com/user_avatar/forum.devtalk.com/andatki/32/5332_2.png) [@andatki](https://forum.devtalk.com/u/andatki)\
**Post date:** [12 July 2025 03:26 UTC](https://forum.devtalk.com/t/high-performance-postgresql-for-rails-explanation-regarding-the-use-of-includes-with-a-limit-page-124/161023/2 "2025-07-12T03:26:22Z")

</div>

Thank you @viktorianer. Your description makes sense. If we revise the book in the future, I’ll pay extra attention to this section, as eager loading is of course a very common pattern.

In my experience, I’ve seen poor performance from big lists of values in an IN clause on big tables. I wrote up some thoughts about this in a blog post here: [Big Problems From Big IN lists with Ruby on Rails and PostgreSQL | Software Engineer, Author, High Performance PostgreSQL for Rails](https://andyatkinson.com/big-problems-big-in-clauses-postgresql-ruby-on-rails)