>
> 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
> unders
On Wed, Oct 23, 2024 at 2:06 AM yudhi s wrote:
>
>
> On Wed, Oct 23, 2024 at 12:32 AM Greg Sabino Mullane
> wrote:
>
>> To be frank, there is so much wrong with this query that it is hard to
>> know where to start. But a few top items:
>>
>> * Make sure all of the tables involved have been analy
On Tue, 2024-10-22 at 13:06 -0700, David G. Johnston wrote:
> On Tue, Oct 22, 2024 at 1:01 PM Ron Johnson wrote:
> > On Tue, Oct 22, 2024 at 3:02 PM Greg Sabino Mullane
> > wrote:
> > > * Don't use the "FROM table1, table2, table3" syntax but use "FROM table1
> > > JOIN table2 ON (...) JOIN tab
On Wed, Oct 23, 2024 at 12:32 AM Greg Sabino Mullane
wrote:
> To be frank, there is so much wrong with this query that it is hard to
> know where to start. But a few top items:
>
> * Make sure all of the tables involved have been analyzed. You might want
> to bump default_statistics_target up and
On Tue, Oct 22, 2024 at 1:01 PM Ron Johnson wrote:
> On Tue, Oct 22, 2024 at 3:02 PM Greg Sabino Mullane
> wrote:
> [snip]
>
>> * Don't use the "FROM table1, table2, table3" syntax but use "FROM table1
>> JOIN table2 ON (...) JOIN table3 ON (...)
>>
>
> Why?
>
>
Readability is improved when done
On Tue, Oct 22, 2024 at 3:02 PM Greg Sabino Mullane
wrote:
[snip]
> * Don't use the "FROM table1, table2, table3" syntax but use "FROM table1
> JOIN table2 ON (...) JOIN table3 ON (...)
>
Why?
--
Death to , and butter sauce.
Don't boil me, I'm still alive.
crustacean!
To be frank, there is so much wrong with this query that it is hard to know
where to start. But a few top items:
* Make sure all of the tables involved have been analyzed. You might want
to bump default_statistics_target up and see if that helps.
* As mentioned already, increase work_mem, as you
On 10/21/24 23:31, yudhi s wrote:
On Thu, Oct 17, 2024 at 3:06 AM Peter J. Holzer wrote:
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 i
On Thu, Oct 17, 2024 at 3:06 AM Peter J. Holzer wrote:
>
> 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
On Thu, Oct 17, 2024 at 3:06 AM Peter J. Holzer 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 a
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 s
On 10/16/24 10:50 AM, yudhi s wrote:
Hi,
Below question got in one discussion.Appreciate any guidance on this.
Below is a query which is running for ~40 seconds. As it's a query which
is executed from UI , we were expecting it to finish in <~5 seconds. It
has a "IN" and a "NOT IN" subquery
Hi,
Below question got in one discussion.Appreciate any guidance on this.
Below is a query which is running for ~40 seconds. As it's a query which is
executed from UI , we were expecting it to finish in <~5 seconds. It has a
"IN" and a "NOT IN" subquery , from the execution path it seems the tota
13 matches
Mail list logo
