On Thu, Jul 16, 2009 at 4:32 PM, Tom Lane<t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
