Re: plan cache overhead on plpgsql expression
От | Tom Lane |
---|---|
Тема | Re: plan cache overhead on plpgsql expression |
Дата | |
Msg-id | 11118.1585231340@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: plan cache overhead on plpgsql expression (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: plan cache overhead on plpgsql expression
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2020-03-25 17:51:50 -0400, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: >>> Hm, any chance that the multiple resowner calls here could show up in a >>> profile? Probably not? >> Doubt it. On the other hand, as the code stands it's certain that the >> resowner contains nothing but plancache pins (while I was writing the >> patch it wasn't entirely clear that that would hold). So we could >> drop the two unnecessary calls. There are assertions in >> ResourceOwnerDelete that would fire if we somehow missed releasing >> anything, so it doesn't seem like much of a maintenance hazard. > One could even argue that that's a nice crosscheck: Due to the later > release it'd not actually be correct to just add "arbitrary" things to > that resowner. I had a thought about a possibly-cleaner way to do this. We could invent a resowner function, say ResourceOwnerReleaseAllPlanCacheRefs, that explicitly releases all plancache pins it knows about. So plpgsql would not call the regular ResourceOwnerRelease entry point at all, but just call that and then ResourceOwnerDelete, again relying on the assertions therein to catch anything not released. This would be slightly more code but it'd perhaps make it clearer what's going on, without the cost of a duplicative data structure. Perhaps in future there'd be use for similar calls for other resource types. regards, tom lane
В списке pgsql-hackers по дате отправления: