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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: MARK CALLAGHAN <mdcallag(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: debugging what might be a perf regression in 17beta2
Date: 2024-07-06 03:48:01
Message-ID: CAApHDvrXQrZrwO=g6SFLaDxwaOX17DR7ThtYoS8QZ44hQX4Fww@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-07-06 05:41:21 Re: Use generation memory context for tuplestore.c
Previous Message MARK CALLAGHAN 2024-07-06 03:11:08 debugging what might be a perf regression in 17beta2