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 > LWLocks? Definitely not. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
