Re: pb with join plan

On Wed, Jun 21, 2023 at 12:43 PM Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
wrote:

> On 6/21/23 00:26, Marc Millas wrote:
> >
> >
> > On Tue, Jun 20, 2023 at 11:19 PM David Rowley <dgrowleyml(at)gmail(dot)com
> > <mailto:dgrowleyml(at)gmail(dot)com>> wrote:
> >
> > On Wed, 21 Jun 2023 at 08:34, Marc Millas <marc(dot)millas(at)mokadb(dot)com
> > <mailto:marc(dot)millas(at)mokadb(dot)com>> wrote:
> > >
> > > On Tue, Jun 20, 2023 at 10:14 PM David Rowley
> > <dgrowleyml(at)gmail(dot)com <mailto:dgrowleyml(at)gmail(dot)com>> wrote:
> > >>
> > >> On Wed, 21 Jun 2023 at 07:42, Marc Millas <marc(dot)millas(at)mokadb(dot)com
> > <mailto:marc(dot)millas(at)mokadb(dot)com>> 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