Amit Kapila <amit.kapil...@gmail.com> wrote on 06/07/2017 07:34:06 AM:
...
> > The down side is that on smaller configurations (single socket) where
there
> > is less "lock thrashing" in the storage subsystem and there are
multiple
> > Lwlocks to take for an exclusive acquire, there is a decided downturn
in
> > performance. On hammerdb, the prototype was 6% worse than the base on
a
> > single socket power configuration.
> >
>
> I think any patch having 6% regression on one machine configuration
> and 16% improvement on another machine configuration is not a net win.
> However, if there is a way to address the regression, then it will
> look much attractive.
I have to agree.
>
> > If there is interest in this approach, I will submit a patch.
> >
>
> The basic idea is clear from your description, but it will be better
> if you share the patch as well. It will not only help people to
> review and provide you feedback but also allow them to test and see if
> they can reproduce the numbers you have mentioned in the mail.
OK -- would love the feedback and any suggestions on how to mitigate the
low end problems.
>
> There is some related work which was previously proposed in this area
> ("Cache the snapshot") [1] and it claims to reduce contention around
> ProcArrayLock. I am not sure if that patch still applies, however, if
> you find it relevant and you are interested in evaluating the same,
> then we can request the author to post a rebased version if it doesn't
> apply.
Sokolov Yura has a patch which, to me, looks good for pgbench rw
performance. Does not do so well with hammerdb (about the same as base)
on single socket and two socket.
>
> [1] - https://www.postgresql.org/message-id/
> CAD__OuiwEi5sHe2wwQCK36Ac9QMhvJuqG3CfPN%2BOFCMb7rdruQ%40mail.gmail.com
>
> --
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>
