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 14:59:01 |
Message-ID: | 3578287.1711637941@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:
> I sort of assumed you were going to commit the patch as you had it.
OK, I will move ahead on that.
> I actually
> really wish we could find some way of making subtransactions
> significantly lighter-wait, because I think the cost of spinning up
> and tearing down a trivial subtransaction is a real performance
> problem, but fixing that is probably a pretty hard problem whether
> this patch gets committed or not.
Yeah. The whole ResourceOwner mechanism is not exactly lightweight,
but it's hard to argue that we don't need it. I wonder whether we
could get anywhere by deeming that a "small enough" subtransaction
doesn't need to have its resources cleaned up instantly, and
instead re-use its ResourceOwner to accumulate resources of the
next subtransaction, and the next, until there's enough to be
worth cleaning up.
Having said that, it's hard to see any regime under which tied-up
parallel workers wouldn't count as a resource worth releasing ASAP.
I started this mail with the idea of suggesting that parallel contexts
ought to become a ResourceOwner-managed resource, but maybe that
wouldn't be an improvement after all.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2024-03-28 15:00:00 | To what extent should tests rely on VACUUM ANALYZE? |
Previous Message | Robert Haas | 2024-03-28 14:22:25 | Re: [PATCH] plpython function causes server panic |