Skip to main content
edited body
Source Link
jjanes
  • 41.3k
  • 3
  • 40
  • 54

Reading 11,378,536 rows isn't magically fast just because you do it with an index. And that is where the problem is, it has to read that number of rows.

We don't know which parts of that complex filter condition lead to most of the rows failing, which makes it hard to propose optimizations with confidence. Maybe inan index on (type, counter) or (type, user_id) would help. Or you could break the query into 2 pieces on the OR condition, and combine them with a UNION.

Reading 11,378,536 rows isn't magically fast just because you do it with an index. And that is where the problem is, it has to read that number of rows.

We don't know which parts of that complex filter condition lead to most of the rows failing, which makes it hard to propose optimizations with confidence. Maybe in index on (type, counter) or (type, user_id) would help. Or you could break the query into 2 pieces on the OR condition, and combine them with a UNION.

Reading 11,378,536 rows isn't magically fast just because you do it with an index. And that is where the problem is, it has to read that number of rows.

We don't know which parts of that complex filter condition lead to most of the rows failing, which makes it hard to propose optimizations with confidence. Maybe an index on (type, counter) or (type, user_id) would help. Or you could break the query into 2 pieces on the OR condition, and combine them with a UNION.

Source Link
jjanes
  • 41.3k
  • 3
  • 40
  • 54

Reading 11,378,536 rows isn't magically fast just because you do it with an index. And that is where the problem is, it has to read that number of rows.

We don't know which parts of that complex filter condition lead to most of the rows failing, which makes it hard to propose optimizations with confidence. Maybe in index on (type, counter) or (type, user_id) would help. Or you could break the query into 2 pieces on the OR condition, and combine them with a UNION.