Re: debugging what might be a perf regression in 17beta2 - Mailing list pgsql-hackers

From MARK CALLAGHAN
Subject Re: debugging what might be a perf regression in 17beta2
Date
Msg-id CAFbpF8O9Y0=LbSWOEmOohqrZ566DiYmNgg1o3Koa_c0Bfsx0LQ@mail.gmail.com
Whole thread Raw
In response to Re: debugging what might be a perf regression in 17beta2  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: debugging what might be a perf regression in 17beta2
List pgsql-hackers
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@gmail.com> wrote:
On Sat, 6 Jul 2024 at 15:11, MARK CALLAGHAN <mdcallag@gmail.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@gmail.com

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Should we work around msvc failing to compile tab-complete.c?
Next
From: MARK CALLAGHAN
Date:
Subject: Re: debugging what might be a perf regression in 17beta2