Search Postgresql Archives

Re: full outer join performance

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

 



Tom Lane wrote:

I think the problem was that he had

	select ... from a, b full join c on ... where ...

where table b is big and you only need a few rows from it, so it really
needs to be joined last, but the above forced doing it first.  It wasn't
clear to me why he wanted the full join at all (in fact, you could see
from the plan that the planner had been able to reduce it to a left join
because there were WHERE clauses that'd discard one set of null-extended
rows anyway).  Without knowing that, it's hard to say whether there's
another way to get what he wants.

Without the outer join, the output was missing the joined rows from a and b when there was no matching row in c. (Tables a and c both referenced b.)

I suppose I could have used a left join instead of a full join, but either way the results were much slower than an inner join, and I was able to redo some other logic to let an inner join work just fine.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
      message can get through to the mailing list cleanly

[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 Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux