Kevin Bond

Hey Ben, thanks for looking into this! > https://github.com/zenstruck/collection/blob/fc126936e76d24ba6c5ad49df6b1e7eefe9cb62c/src/Collection/Doctrine/ORM/EntityResult.php#L331-L333 > > So, I've forced setUseOutputWalkers(false) to be called by overriding the controller action and specifying a modifier which does nothing...

So an index w/o `setUseOutputWalkers(false)` doesn't improve performance? > I think you can probably l isten to postGenerateSchema and do We can't assume the user named the table `processed_messages`. I...

What about using `->asArray()`? ```php #[Route('/_recent-messages', name: 'zenstruck_messenger_monitor_recent_messages_widget')] public function recentMessagesWidget( ViewHelper $helper, ): Response { return $this->render('@ZenstruckMessengerMonitor/components/recent_messages.html.twig', [ 'messages' => Specification::new()->snapshot($helper->storage())->messages()->asArray(), 'helper' => $helper, ]); } ```

Oh right, I misread your code above. So is this slowness only on the dashboard - not on `/history`?

In zenstruck/collection, I already have `EntityResult->disableFetchJoins()` which modifies the behaviour of the paginator. I'm thinking to add `EntityResult->enableOutputWalkers()` && `EntityResult->enableOutputWalkers()` also. Then, in this bundle, use `->disableOutputWalkers()` where applicable.

> ah, so the fix can be changed to use disableFetchJoins instead: So wait, `->disableFetchJoins()` + adding an index to `finishedAt` has the same effect?

Ah ok, cool, so to fix this, change: https://github.com/zenstruck/messenger-monitor-bundle/blob/fd3fcc0929f0a91f2fd3edb6fe954be706874547/src/History/Storage/ORMStorage.php#L53 to ```php return (new EntityResult($this->queryBuilderFor($specification))->disableFetchJoins(); ``` and document adding the index?

I think it would - at least for query that lists messages. Wondering if the other queries (methods in `ORMStorage`) can be optimized?

I'll need you to confirm on your giant database 😆

Might need some additional indexes?