> Maybe it can be misleading sometimes, but I feel sometimes it is more > informative compared to the optimized build where it makes some function > inline, and then it becomes really hard to distinguish which function > really has the problem. But your point is taken and I will run with an > optimized build. >
IMHO Andres is right optimization may make profiles mostly useless in most cases - it may skew timings for different parts differently, so something that'd be optimized out may take much more time.
It may provide valuable insights, but we definitely should not use such binaries for benchmarking and comparisons of the patches.
Yeah, I completely agree that those binaries should not be used for benchmarking and patch comparison and I never used it for that purpose. I was also making the same point that with debug binaries sometimes we get some valuable insight during profiling.
As mentioned, I did some benchmarks, and I do see some nice improvements even with properly optimized builds -O2.
Attached is a simple script that varies a bunch of parameters (number of workers, number of rows/columns, ...) and then measures duration of a simple query, similar to what you did. I haven't varied the queue size, that might be interesting too.
The PDF shows a comparison of master and the two patches. For 10k rows there's not much difference, but for 1M and 10M rows there are some nice improvements in the 20-30% range. Of course, it's just a single query in a simple benchmark.