I have _not_ added a TODO for this item. Let me know if one is needed.
---------------------------------------------------------------------------
Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> 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@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +