On Thu, Oct 17, 2024 at 3:06 AM Peter J. Holzer <hjp-pgsql@xxxxxx> wrote:
On 2024-10-16 23:20:36 +0530, yudhi s wrote:
> Below is a query which is running for ~40 seconds.
[...]
> In the execution path below , the line number marked in bold are the top lines
> for the IN and NOT IN subquery evaluation and they are showing "Actual time" as
> Approx ~9 seconds and ~8 seconds and they seems to be summed up and the top
> lines showing it to be ~19 seconds. Then onwards it keeps on increasing with
> other "nested loop" joins.
>
> Note:- This query is running on a MYSQL 8.0 database. So I'm wondering if there
> is any mysql list similar to Oracle list , in which i can share this issue?
The execution plan looks like a postgresql execution plan, not a mysql
execution plan. Did you run this query on postgresql? That may be
interesting for comparison purposese, but ultimately it is useless: You
won't get mysql to work like postgresql, and any tips to speed up this
query on postgresql (which is all you can expect on a postgresql mailing
list) probably won't work on mysql.
Agreed. Postgres and mysql may have differences in how the optimizer is interpreting the stats and coming up with the execution oath. However, I was looking if the query can be written efficiently by tweaking the current logic. It's actually spending the majority of the time doing the "IN" and "NOT IN" evaluation and in that it's using the same exact subquery for the "UNION ALL" . And the overall execution time is summation of the IN and NOT IN clause evaluation. So I was thinking of a better way of writing the same logically.
