Re: Gather performance analysis

On Wed, Sep 8, 2021 at 3:28 PM Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)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