On Tue, Feb 27, 2018 at 4:06 PM, Andres Freund <and...@anarazel.de> wrote: >> OK, I'll try to check how feasible that would be. > > cool.
It's not too hard, but it doesn't really seem to help, so I'm inclined to leave it alone. To make it work, you need to keep two separate counters in the shm_mq_handle, one for the number of bytes since we did an increment and the other for the number of bytes since we sent a signal. I don't really want to introduce that complexity unless there is a benefit. With just 0001 and 0002: 3968.899 ms, 4043.428 ms, 4042.472 ms, 4142.226 ms With two-separate-counters.patch added: 4123.841 ms, 4101.917 ms, 4063.368 ms, 3985.148 ms If you take the total of the 4 times, that's an 0.4% slowdown with the patch applied, but I think that's just noise. It seems possible that with a larger queue -- and maybe a different query shape it would help, but I really just want to get the optimizations that I've got committed, provided that you find them acceptable, rather than spend a lot of time looking for new optimizations, because: 1. I've got other things to get done. 2. I think that the patches I've got here capture most of the available benefit. 3. This case isn't super-common in the first place -- we generally want to avoid feeding tons of tuples through the Gather. 4. We might abandon the shm_mq approach entirely and switch to something like sticking tuples in DSA using the flexible tuple slot stuff you've proposed elsewhere. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
0002-shm-mq-reduce-receiver-latch-set-v3.patch
Description: Binary data
0001-shm-mq-less-spinlocks-v4.patch
Description: Binary data
two-separate-counters.patch
Description: Binary data
