Re: Postgres: Queries are too slow after upgrading to PG17 from PG15
От | Peter Geoghegan |
---|---|
Тема | Re: Postgres: Queries are too slow after upgrading to PG17 from PG15 |
Дата | |
Msg-id | CAH2-Wzm60M3nRDkQ-VpMYbLRDrQ0JRcWVFfOtkmW2f3JQ4HfCQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Postgres: Queries are too slow after upgrading to PG17 from PG15 (Merlin Moncure <mmoncure@gmail.com>) |
Список | 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 по дате отправления: