Re: Postgres: Queries are too slow after upgrading to PG17 from PG15 - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: Postgres: Queries are too slow after upgrading to PG17 from PG15
Date
Msg-id CAH2-Wzm60M3nRDkQ-VpMYbLRDrQ0JRcWVFfOtkmW2f3JQ4HfCQ@mail.gmail.com
Whole thread Raw
In response to Re: Postgres: Queries are too slow after upgrading to PG17 from PG15  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-bugs
On Wed, Jul 30, 2025 at 2:59 PM Merlin Moncure <mmoncure@gmail.com> wrote:
> side question: if 50% of time (per perf top) is spent in qsort and
> subroutines, how come query time goes down ~85%? is this a limitation
> of perf or some other issue?

I used perf's default event type for this, which is "cycles". It's
well known that the relationship between cycles and wallclock time is
very complicated. In my experience "cycles" tends to be useful for a
first order pass, to get a very general sense of what's going on,
before considering possible solutions. That's all I needed here -- I
wasn't trying to be precise.

Separately, there's bound to be complicated nonlinear effects in play.
That's one of the reasons why it is so hard to apply profiling
information effectively, at least when optimizing a given piece of
code that is already reasonably well understood.

> side question #2: 32% time spent on FunctionCall2Coll seems like a lot
> -- is this inclusive of the routine under the function pointer?
>
> just curious on both of these

I ran perf in a way that counted FunctionCall2Coll separately from
btint8cmp. It's not that surprising that FunctionCall2Coll dominated,
since btint8cmp is so simple.

--
Peter Geoghegan



pgsql-bugs by date:

Previous
From: Todd Cook
Date:
Subject: Re: Postgres: Queries are too slow after upgrading to PG17 from PG15
Next
From: Peter Geoghegan
Date:
Subject: Re: Postgres: Queries are too slow after upgrading to PG17 from PG15