Re: debugging what might be a perf regression in 17beta2
От | David Rowley |
---|---|
Тема | Re: debugging what might be a perf regression in 17beta2 |
Дата | |
Msg-id | CAApHDvrXQrZrwO=g6SFLaDxwaOX17DR7ThtYoS8QZ44hQX4Fww@mail.gmail.com обсуждение исходный текст |
Ответ на | debugging what might be a perf regression in 17beta2 (MARK CALLAGHAN <mdcallag@gmail.com>) |
Ответы |
Re: debugging what might be a perf regression in 17beta2
|
Список | pgsql-hackers |
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% slowerthere. > > 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
В списке pgsql-hackers по дате отправления: