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

A writeup for the benchmark results is here -
https://smalldatum.blogspot.com/2024/07/postgres-17beta2-vs-sysbench-looking.html
pg17beta2 and pg17beta1 look good so far

On Mon, Jul 8, 2024 at 10:49 AM MARK CALLAGHAN <mdcallag(at)gmail(dot)com> wrote:

> 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
>

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