Julien Rouhaud <rjuju...@gmail.com> writes: > On Fri, Jan 14, 2022 at 07:42:29PM +0000, Bossart, Nathan wrote: >> On 1/14/22, 8:26 AM, "Tom Lane" <t...@sss.pgh.pa.us> wrote: >>> It feels to me like far too much effort is being invested in fundamentally >>> the wrong direction here.
> Agreed, it would be better but if that leads to significant work that doesn't > land in pg15, it would be nice to at least get more monitoring possibilities > in pg15 to help locate problems in application. The discussion just upthread was envisioning not only that we'd add infrastructure for this, but then that other projects would build more infrastructure on top of that. That's an awful lot of work that will become useless --- indeed maybe counterproductive --- once we find an actual fix. I say "counterproductive" because I wonder what compatibility problems we'd have if the eventual fix results in fundamental changes in the way things work in this area. Since it's worked the same way for a lot of years, I'm not impressed by arguments that we need to push something into v15. >> An easy first step might be to increase PGPROC_MAX_CACHED_SUBXIDS and >> NUM_SUBTRANS_BUFFERS. I don't think that's an avenue to a fix. We need some more-fundamental rethinking about how this should work. (No, I don't have any ideas at the moment.) > There's also something proposed at > https://www.postgresql.org/message-id/003201d79d7b$189141f0$49b3c5d0$@tju.edu.cn, > which seems to reach some nice improvement without a major redesign of the > subtransaction system, but I now realize that apparently no one added it to > the > commitfest :( Hmm ... that could win if we're looking up the same subtransaction's parent over and over, but I wonder if it wouldn't degrade a lot of workloads too. regards, tom lane