subtransaction performance
Hi,
I stumbled over:
I wonder if SAVEPOINT / subtransaction performance has been boosted since
the blog was written.
Cheers
On Fri, Oct 7, 2022 at 03:23:27PM -0700, Zhihong Yu wrote:
Hi,
I stumbled over:https://about.gitlab.com/blog/2021/09/29/
why-we-spent-the-last-month-eliminating-postgresql-subtransactions/I wonder if SAVEPOINT / subtransaction performance has been boosted since the
blog was written.
No, I have not seen any changes in this area since then. Seems there
are two problems --- the 64 cache per session and the 64k on the
replica. In both cases, it seems sizing is not optimal, but sizing is
never optimal. I guess we can look at allowing manual size adjustment,
automatic size adjustment, or a different approach that is more graceful
for larger savepoint workloads.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
On Mon, Oct 10, 2022 at 02:20:37PM -0400, Bruce Momjian wrote:
On Fri, Oct 7, 2022 at 03:23:27PM -0700, Zhihong Yu wrote:
I wonder if SAVEPOINT /�subtransaction performance has been boosted since the
blog was written.No, I have not seen any changes in this area since then. Seems there
are two problems --- the 64 cache per session and the 64k on the
replica. In both cases, it seems sizing is not optimal, but sizing is
never optimal. I guess we can look at allowing manual size adjustment,
automatic size adjustment, or a different approach that is more graceful
for larger savepoint workloads.
I believe the following commitfest entries might be relevant to this
discussion:
https://commitfest.postgresql.org/39/2627/
https://commitfest.postgresql.org/39/3514/
https://commitfest.postgresql.org/39/3806/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Oct 10, 2022 at 08:34:33PM -0700, Nathan Bossart wrote:
On Mon, Oct 10, 2022 at 02:20:37PM -0400, Bruce Momjian wrote:
On Fri, Oct 7, 2022 at 03:23:27PM -0700, Zhihong Yu wrote:
I wonder if SAVEPOINT / subtransaction performance has been boosted since the
blog was written.No, I have not seen any changes in this area since then. Seems there
are two problems --- the 64 cache per session and the 64k on the
replica. In both cases, it seems sizing is not optimal, but sizing is
never optimal. I guess we can look at allowing manual size adjustment,
automatic size adjustment, or a different approach that is more graceful
for larger savepoint workloads.I believe the following commitfest entries might be relevant to this
discussion:https://commitfest.postgresql.org/39/2627/
https://commitfest.postgresql.org/39/3514/
https://commitfest.postgresql.org/39/3806/
Wow, odd that I missed those. Yes, they are very relevant. :-)
The only other idea I had was to report such overflows, but these are
better.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson