Julien Rouhaud <rjuju123@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" <tgl@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