Replies: 2 comments 1 reply
-
Weird that it would be so slow. Note that |
Beta Was this translation helpful? Give feedback.
-
Great point, I hadn't considered the to-many join scenario since my use case was only operating on a single table.
I did come across this post that hints at why the table scan is occurring:
Our use case does in fact fall into this scenario, the query above is filtering out about 7% of the rows. However the overall # of rows is only around 36k, it appears what is really taking a lot of the time is the use of the distinct. Running an analyze on the same query but with the distinct removed gives me:
This is still a slight bit slower than the |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
I'm not sure this is a bug or if it's intended behavior but figured I'd raise it and seek some clarification.
When I'm performing a
findAndCount
operation, the count SQL that is being generated is usingcount(distinct(e0.id))
rather than simplycount(*)
.Running an analyze on the
count(distinct(e0.id))
query reveals that it's running a full table scan:Whereas the simpler
count(*)
:The count(*) has almost a full order of magnitude better performance so I'm just wondering if there's a reason the count query is being generated the way it is.
To Reproduce
I'm specifying my entity and schemas separately, something similar to:
Entity:
Schema:
And a simplified query `const [events, count] = await em.findAndCount(Event, {endTime: {$lt: new Date()}})
Expected behavior
I'd expect the count query to be using
count(*)
rather than counting by distinct id, especially since that ID is specified as the only PK on the table (unless of course I'm missing something here).Versions
Beta Was this translation helpful? Give feedback.
All reactions