"Kevin Grittner" <Kevin.Grittner@xxxxxxxxxxxx> writes: > We do have a few queries where PostgreSQL is several orders of > magnitude slower. It appears that the reason it is choosing a bad plan > is that it is reluctant to start from a subquery when there is an outer > join in the FROM clause. AFAICT this case doesn't really hinge on the outer join at all. The problem is that EXISTS subqueries aren't well optimized. I would have expected an equivalent IN clause to work better. In fact, I'm not clear why the planner isn't finding the cheapest plan (which it does estimate as cheapest) from the IN version you posted. What PG version is this exactly? > ... The third query is the fastest, but isn't > portable enough for our mixed environment. Not really relevant to the problem, but what's wrong with it? Looks like standard SQL to me. regards, tom lane
