On 2016-08-16 23:09:07 -0400, Robert Haas wrote:
> On Tue, Aug 16, 2016 at 5:03 PM, Andres Freund <and...@anarazel.de> wrote:
> > On 2016-08-15 18:15:23 -0400, Robert Haas wrote:
> >> On Thu, Aug 11, 2016 at 2:19 PM, Robert Haas <robertmh...@gmail.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
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: