From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Hao Zhang <zhrt1446384557(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] plpython function causes server panic |
Date: | 2024-03-28 15:50:30 |
Message-ID: | 3583862.1711641030@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2024-03-28 15:58:31 | Re: ALTER TABLE SET ACCESS METHOD on partitioned tables |
Previous Message | Robert Haas | 2024-03-28 15:27:10 | Re: [PATCH] plpython function causes server panic |