Ron Mayer <rm_pg@xxxxxxxxxxxxxxxxxxxxxxx> writes: > Tom Lane wrote: >> There's something fishy about this --- given that that plan has a lower >> cost estimate, it should've picked it without any artificial >> constraints. > I think the reason it's not picking it was discussed back in this thread > too. > http://archives.postgresql.org/pgsql-performance/2005-03/msg00675.php > http://archives.postgresql.org/pgsql-performance/2005-03/msg00684.php > My offset 0 is forcing the outer join. > [Edit: Ugh - meant cartesian join - which helps this kind of query.] Ah; I missed the fact that the two relations you want to join first don't have any connecting WHERE clause. The concern I mentioned in the above thread was basically that I don't want the planner to go off chasing Cartesian join paths in general --- they're usually useless and would result in an exponential explosion in the number of join paths considered in many-table queries. However, in this case the reason that the Cartesian join might be relevant is that both of them are needed in order to form an inner indexscan on the big table. I wonder if we could drive consideration of the Cartesian join off of noticing that. It'd take some rejiggering around best_inner_indexscan(), or somewhere in that general vicinity. Way too late for 8.3, but something to think about for next time. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
