# I caricamenti degli argomenti sono lenti o non avvengono affatto quando hanno molte risposte e l'utente ha un segnalibro al loro interno

**URL:** https://meta.discourse.org/t/topics-load-slow-or-not-at-all-when-they-have-many-replies-and-user-has-bookmark-in-them/166201
**Category:** Bug
**Created:** [4 Ottobre 2020, 3:26pm UTC](https://meta.discourse.org/t/topics-load-slow-or-not-at-all-when-they-have-many-replies-and-user-has-bookmark-in-them/166201 "2020-10-04T15:26:50Z")
**Posts on this page:** 1
**Showing post:** 8

<div class="post-metadata">

### Author: ![martin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/martin/32/491371_2.png) [@martin](https://meta.discourse.org/u/martin)
#### Post date: [26 Ottobre 2020, 4:32am UTC](https://meta.discourse.org/t/topics-load-slow-or-not-at-all-when-they-have-many-replies-and-user-has-bookmark-in-them/166201/8 "2020-10-26T04:32:25Z")

</div>

Questo è stato corretto in:

> <https://github.com/discourse/discourse/commit/57d06518d419ad067a01ff1dc6836a44d5b4b685>
>
> On forums with a large amount of posts when a user had a bookmark in the topic, …PostgreSQL was using an inefficient query plan to fetch the first post of the topic. When running this ActiveRecord query:
> 
> \`\`\`
> topic.posts.with\_deleted.where(post\_number: 1).first
> \`\`\`
> 
> The following query plan was produced:
> 
> \`\`\`
> Limit (cost=0.43..583.49 rows=1 width=891) (actual time=3850.515..3850.515 rows=1 loops=1)
> -\> Index Scan using posts\_pkey on posts (cost=0.43..391231.51 rows=671 width=891) (actual time=3850.514..3850.514 
> rows=1 loops=1)
> Filter: ((topic\_id = 160918) AND (post\_number = 1))
> Rows Removed by Filter: 2274520
> Planning time: 0.200 ms
> Execution time: 3850.559 ms
> (6 rows)
> \`\`\`
> 
> The issue here is the combination of ORDER BY and LIMIT causing the ineficcient Index Scan using posts\_pkey on posts to be used. When we correct the AR call to this:
> 
> \`\`\`
> topic.posts.with\_deleted.find\_by(post\_number: 1)
> \`\`\`
> 
> We end up with a query that still has a LIMIT but no ORDER BY, which in turn creates a much more efficient query plan:
> 
> \`\`\`
> Limit (cost=0.43..1.44 rows=1 width=891) (actual time=0.033..0.034 rows=1 loops=1)
> -\> Index Scan using index\_posts\_on\_topic\_id\_and\_post\_number on posts (cost=0.43..678.82 rows=671 width=891) (actua
> l time=0.033..0.033 rows=1 loops=1)
> Index Cond: ((topic\_id = 160918) AND (post\_number = 1))
> Planning time: 0.167 ms
> Execution time: 0.072 ms
> (5 rows)
> \`\`\`
> 
> This query plan uses the correct index, \`Index Scan using index\_posts\_on\_topic\_id\_and\_post\_number on posts\`. Note that this is only a problem on forums with a larger amount of posts; tiny forums would not notice the difference. On large forums a query for a topic that takes 1s without a bookmark can take 8-30 seconds, and even end up with 502 errors from nginx.

cc @Macaw che ha creato questo argomento correlato [Bookmarking a Post on a Large Topic creates Absurd Loading Times](https://meta.discourse.org/t/bookmarking-a-post-on-a-large-thread-creates-absurd-loading-times/168041)

---

_[View the full topic](https://meta.discourse.org/t/topics-load-slow-or-not-at-all-when-they-have-many-replies-and-user-has-bookmark-in-them/166201)._
