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. Should we have a separate copy of lwlock.c just for parallel query and other stuff that uses DSM? Won't that slow down every error-handling path in the system, if they all have to release two kinds of lwlocks rather than one? And bloat the binary? Or are you going to argue that parallel query doesn't really need LWLocks? I'm sure that's not true. We got by without it for this release, but that's because the only truly parallel operation as yet is Parallel Seq Scan whose requirements are simple enough to be handled with a spinlock. Anyway, I guess we should wait for the benchmark results and then see, but if we're not going to do this then we need some reasonable alternative. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
