Re: debugging what might be a perf regression in 17beta2

My results have too much variance so this is a false alarm. One day I might
learn whether the noise is from HW, Postgres or my test method.
I ended up trying 10 builds between 17beta1 and 17beta2, but even with that
I don't have a clear signal.

On Fri, Jul 5, 2024 at 8:48 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Sat, 6 Jul 2024 at 15:11, MARK CALLAGHAN <mdcallag(at)gmail(dot)com> wrote:
> > On small servers I have at home I can reproduce the problem without
> concurrent queries and 17beta2 is 5% to 10% slower there.
> >
> > The SQL statement for the scan microbenchmark is:
> > SELECT * from %s WHERE LENGTH(c) < 0
>
> Can you share the CREATE TABLE and script to populate so others can try?
>
> Also, have you tried with another compiler? It does not seem
> impossible that the refactoring done in heapam.c or the read stream
> code might have changed something to make the binary more sensitive to
> caching effects in this area. One thing I often try when I can't
> pinpoint the exact offending commit is to write a script to try the
> first commit of each day for, say, 30 days to see if there is any
> saw-toothing in performance numbers over that period.
>
> David
>

--
Mark Callaghan
mdcallag(at)gmail(dot)com