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 <mdcal...@gmail.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 <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 > -- Mark Callaghan mdcal...@gmail.com
