Kris Jurka <[EMAIL PROTECTED]> writes:
> [ GEQO doesn't work anymore in CVS tip ]
Ugh. The proximate cause of this is the code I added recently to cache
repeated calculations of the best inner indexscan for a given inner
relation with potential outer relations. Since geqo_eval() releases
all memory acquired during construction of a possible jointree, it
releases the cached path info too. The next attempt to use the data
fails.
Naturally, ripping out the cache again doesn't strike me as an appealing
solution.
The narrowest fix would be to hack best_inner_indexscan() to switch into
the context containing the parent RelOptInfo while it makes a cache
entry. This seems kinda klugy but it would work.
I wonder if we'd be better off not trying to reclaim memory in
geqo_eval. Aside from presenting a constant risk of this sort of
problem whenever someone hacks the optimizer, what it's really doing
is discarding a whole lot of join cost estimates that are likely to
be done over again in (some of) the following calls of geqo_eval.
GEQO would certainly be a lot faster if we didn't release that info,
and I'm not sure that the space cost would be as bad as the code
comments claim. Any thoughts?
This really just points up how messy memory management in the optimizer
is at present. I wonder if anyone has ideas on improving it ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
