Re: [BUGS] GEQO Triggers Server Crash
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] GEQO Triggers Server Crash |
Дата | |
Msg-id | 200212110337.gBB3bCE18672@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] GEQO Triggers Server Crash (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] GEQO Triggers Server Crash
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: