Обсуждение: Re: [BUGS] GEQO Triggers Server Crash

Kris Jurka <jurka@ejurka.com> 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

Can we free only the plans we want to free in geqo?  I don't mind having
a different free method in geqo vs. the rest of the optimizer.

---------------------------------------------------------------------------

Tom Lane wrote:
> Kris Jurka <jurka@ejurka.com> 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 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Can we free only the plans we want to free in geqo?  I don't mind having
> a different free method in geqo vs. the rest of the optimizer.

GEQO calls "the rest of the optimizer", and the space that we're
worried about is almost all allocated in "the rest of the optimizer".
How are you going to implement two different free methods?
        regards, tom lane