Search Postgresql Archives

Re: pb with join plan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 









On Wed, Jun 21, 2023 at 12:43 PM Tomas Vondra <tomas.vondra@xxxxxxxxxxxxxxxx> wrote:
On 6/21/23 00:26, Marc Millas wrote:
>
>
> On Tue, Jun 20, 2023 at 11:19 PM David Rowley <dgrowleyml@xxxxxxxxx
> <mailto:dgrowleyml@xxxxxxxxx>> wrote:
>
>     On Wed, 21 Jun 2023 at 08:34, Marc Millas <marc.millas@xxxxxxxxxx
>     <mailto:marc.millas@xxxxxxxxxx>> wrote:
>     >
>     > On Tue, Jun 20, 2023 at 10:14 PM David Rowley
>     <dgrowleyml@xxxxxxxxx <mailto:dgrowleyml@xxxxxxxxx>> wrote:
>     >>
>     >> On Wed, 21 Jun 2023 at 07:42, Marc Millas <marc.millas@xxxxxxxxxx
>     <mailto:marc.millas@xxxxxxxxxx>> wrote:
>     >> > But if I do the same with clause one OR clause 2, I have to 
>     kill the request after an hour, seeing the filesystem showing more
>     than 140 Mb of increased usage.
>     >>
>     >>
>     > link to the anonymized plan of the req with one clause :
>     https://explain.depesz.com/s/TWp4 <https://explain.depesz.com/s/TWp4>
>
> link to the plan with the second
> clause alone: https://explain.depesz.com/s/byW5
> <https://explain.depesz.com/s/byW5
> link to the plan with both clauses ORed (the one not
> finishing) https://explain.depesz.com/s/jHO2
> <https://explain.depesz.com/s/jHO2>
>
>
>
>     It's quite difficult to know what the problem is you want to fix here.
>     Your initial post indicated it was the query with the OR condition
>     that was causing you the problems, but the plan you've posted has no
>     OR condition?!
>
>     You're more likely to get help here if you take time to properly
>     explain the situation and post the information that's actually
>     relevant to the problem you're having, or state the problem more
>     clearly, as there's a mismatch somewhere.
>
>     It might also be worth having a look at
>     https://wiki.postgresql.org/wiki/Slow_Query_Questions
>     <https://wiki.postgresql.org/wiki/Slow_Query_Questions> . EXPLAIN is not
>     going to tell us what part of the query is slow. I'll let the wiki
>     page guide you into what to do instead.
>
>  
> I know that page. obviously, as I have to kill the request, I cannot
> provide a explain analyze... 
>

It's a bit weird the "victor" table is joined seemingly without any join
conditions, leading to a cross join (which massively inflates the cost
for joins above it). Maybe the anonymized plan mangles it somehow.

the query does:
 select blabla from table1 join table2 on (list of 9 fields ANDed and corresponding to the index of both table1 and table2) 
join table3 on table1.a=table3.a and table1.b=table3.b
join table4 on (list of 2 clauses table2.d=table4.e  and one clause substr(table2.f)=table4.g  all ORed)
table1 and table2 are big (15M and 60M lines), table3 and table4 are small (30k lines)

basically, if I rewrites the query beginning by the join between table2 and table4, then join table1 and then table3, postgres generates the same plan, which doesnt end.

if instead of the 3 clauses of the last join I keep one equality clause, the explain plan looks the same, but executes in 45 secondes.



regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

 Marc MILLAS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux