Re: LWLocks in DSM memory

On 2016-08-16 23:09:07 -0400, Robert Haas wrote:
> On Tue, Aug 16, 2016 at 5:03 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > On 2016-08-15 18:15:23 -0400, Robert Haas wrote:
> >> On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >> > Therefore, I plan to commit this patch, removing the #include
> >> > <stddef.h> unless someone convinces me we need it, shortly after
> >> > development for v10 opens, unless there are objections before then.
> >>
> >> Hearing no objections, done.
> >
> > I'd have objected, if I hadn't been on vacation. While I intuitively
> > *do* think that the increased wait-list overhead won't be relevant, I
> > also know that my intuition has frequently been wrong around the lwlock
> > code. This needs some benchmarks on a 4+ socket machine,
> > first. Something exercising the slow path obviously. E.g. a pgbench with
> > a small number of writers, and a large number of writers.
>
> I have to admit that I totally blanked about you being on vacation.
> Thanks for mentioning the workload you think might be adversely
> affected, but to be honest, even if there's some workload where this
> causes a small regression, I'm not really sure what you think we
> should do instead.

Well, you convincingly argued against that approach in a nearby thread
;). Joking aside: I do think that we should make such a change
knowingly. It might also be possible to address it somehow.

I really hope there's no slowdown.

> Should we have a separate copy of lwlock.c just
> for parallel query and other stuff that uses DSM?

No, that'd be horrible.

> Or are you going to argue that parallel query doesn't really need
> LWLocks?

Definitely not.

- Andres