On Mon, Sep 27, 2021 at 1:22 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > I have done testing with different batch sizes, 16k (which is the same > as 1/4 of the queue size with 64k queue size) , 8k, 4k, 2k. > > In the attached sheet I have done a comparison of > 1. head vs patch (1/4 queue size) = execution time reduced to 37% to > 90% this is the same as the old sheet. > 2. patch (1/4 queue size) vs patch(8k batch) = both are same, but 8k > batch size is slow in some cases. > 3. patch (1/4 queue size) vs patch(4k batch) = both are same, but 4k > batch size is slow in some cases (even slower than 8k batch size). > 4. patch (1/4 queue size) vs patch(2k batch) = 2k batch size is > significantly slow.
Generally these results seem to show that a larger batch size is better than a smaller one, but we know that's not true everywhere and under all circumstances, because some of Tomas's numbers are worse than the unpatched cases. And I think we don't really understand the reason for those results. Now it could be that there's no really good reason for those results, and it's just something weird or not very generally interesting. On the other hand, while it's easy to see that batching can be a win if it avoids contention, it also seems easy to imagine that it can be a loss. By postponing the update to shared memory, we are essentially gambling. If nobody would have read the updated value anyway, we win, because we avoided doing work that wasn't really needed by consolidating multiple updates of shared memory down to one. However, imagine the scenario where someone reads a value that is small enough that they have to block, because they think there's no more data available. If there really is more data available and we just didn't update shared memory, then we lose. Here, the wins are going to be much smaller than the losses. Cache line contention isn't cheap, but it's a lot cheaper than actually having a process go to sleep and having to wake it up again. So essentially the patch is betting that the winning scenario is much more common than the losing scenario - the occasional big losses when the reader sleeps unnecessarily will be more than counterbalanced by the small wins every time we skip an update to shared memory without causing that to happen. And most of the time, that's probably a good bet. But, if you do somehow hit the losing case repeatedly, then you could see a significant regression. And that might explain Tomas's results. Perhaps for some reason they just happen to hit that case over and over again. If that's true, it would be useful to know why it happens in that case and not others, because then maybe we could avoid the problem somehow. However, I'm not sure how to figure that out, and I'm not even entirely sure it's important to figure it out. -- Robert Haas EDB: http://www.enterprisedb.com
