Re: Query performance issue

From: Greg Sabino Mullane <htamfids(at)gmail(dot)com>
To: yudhi s <learnerdatabase99(at)gmail(dot)com>
Cc: jross(at)openvistas(dot)net, pgsql-general(at)lists(dot)postgresql(dot)org, hjp-pgsql(at)hjp(dot)at
Subject: Re: Query performance issue
Date: 2024-10-24 14:01:21
Message-ID: CAKAnmmL_=6PjxSJD105oSSfEPiCyk_KQp5ZCPz2AsdunznOXeA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>
> Additionally in the plan which mysql makes and showing the highest
> response time, is it suffering because of differences of the speed of the
> underlying IO/storage or is it just because of the optimization features
> which are available in postgres and not there in mysql ? Trying to
> understand if it can be identified from the execution plan itself.
>

I think trying to compare postgres and mysql plans against each other is
not a very useful endeavor. There are fundamental design decisions between
the two. Focus on making your Postgres query the best it can be, full stop.
Optimize your queries, make sure the database is analyzed, and tweak some
configs as needed.

Also, you cannot accidentally forget a join condition.

Yes, this is the primary reason. Cartesian joins hurt.

Again , not able to clearly understand the third point you said below. Can
> you please clarify a bit more. Do you mean we should write it as exists
> /not exists rather IN and NOT IN and that will improve the performance?

It gives Postgres more options on how to do things, so yes, it can be
better.

Cheers,
Greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Igor Korot 2024-10-24 16:12:09 Re: Assistance Required: Timeout or Buffer Overflow Issue in PostgreSQL Client Application
Previous Message Muhammad Ikram 2024-10-24 13:01:09 Re: CURRENTE_DATE