On Wed, Jun 21, 2023 at 12:43 PM Tomas Vondra <tomas.von...@enterprisedb.com> wrote:
> On 6/21/23 00:26, Marc Millas wrote: > > > > > > On Tue, Jun 20, 2023 at 11:19 PM David Rowley <dgrowle...@gmail.com > > <mailto:dgrowle...@gmail.com>> wrote: > > > > On Wed, 21 Jun 2023 at 08:34, Marc Millas <marc.mil...@mokadb.com > > <mailto:marc.mil...@mokadb.com>> wrote: > > > > > > On Tue, Jun 20, 2023 at 10:14 PM David Rowley > > <dgrowle...@gmail.com <mailto:dgrowle...@gmail.com>> wrote: > > >> > > >> On Wed, 21 Jun 2023 at 07:42, Marc Millas <marc.mil...@mokadb.com > > <mailto:marc.mil...@mokadb.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
