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 <dgrowle...@gmail.com> wrote: > On Sat, 6 Jul 2024 at 15:11, MARK CALLAGHAN <mdcal...@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 mdcal...@gmail.com
