On Thu, Jul 16, 2009 at 4:32 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> samples % image name symbol name
> 886498 53.8090 postgres have_relevant_eclass_joinclause
> 460596 27.9574 postgres bms_overlap
>
> So maybe a redesign of the equivalence-class joinclause mechanism is in
> order. Still, this is unlikely to fix the fundamental issue that the
> time for large join problems grows nonlinearly.
Perhaps it's GEQO's fault that it's using these functions
inappropriately, calling them often to calculate these answers
whenever it needs them instead of looking once for join clauses and
then optimizing based on the results. But I've never actually looked
at geqo, mabe that's inherent in the design?
--
greg
http://mit.edu/~gsstark/resume.pdf
