On Wed, Sep 8, 2021 at 3:28 PM Tomas Vondra <tomas.von...@enterprisedb.com> wrote:
On 9/8/21 9:40 AM, Dilip Kumar wrote: > > > 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. > Thanks for the benchmarking. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
