Re: [PATCH] plpython function causes server panic
От | Tom Lane |
---|---|
Тема | Re: [PATCH] plpython function causes server panic |
Дата | |
Msg-id | 3583862.1711641030@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] plpython function causes server panic (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] plpython function causes server panic
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > Hmm, I wonder if that's actually where the cycles are going. There's > an awful lot of separate function calls inside CommitSubTransaction(), > and in the common case, each one of them has to individually decide > that it doesn't need to do anything. Sure, they're all fast, but if > you have enough of them, it's still going to add up, at least a bit. > In that sense, the resource owner mechanism seems like it should, or > at least could, be better. Yeah, I was thinking about that too. The normal case is that you don't hold any releasable resources except locks when arriving at CommitSubTransaction --- if you do, it's a bug and we're going to print leak warnings. Seems like maybe it'd be worth trying to have a fast path for that case. (Also, given that we probably do need to release locks right away, this point invalidates my earlier idea of postponing the work.) > But I haven't done any benchmarking of this area in a long time. Ditto. regards, tom lane
В списке pgsql-hackers по дате отправления: