I have _not_ added a TODO for this item. Let me know if one is needed. --------------------------------------------------------------------------- Tom Lane wrote: > 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 -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
