From: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: A tidyup of pathkeys.c |
Date: | 2025-10-14 23:49:08 |
Message-ID: | 32B21F24-9EF5-4670-A24F-5CF0BC923A52@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Oct 14, 2025, at 19:22, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> What makes you think making them inline would make the performance the
> same as before? The previous functions were not inlined, and I've not
> made any changes that should affect the compiler's ability to choose
> to inline these functions or not.
Ah… You are right. The old code:
static int
pathkeys_useful_for_ordering(PlannerInfo *root, List *pathkeys)
{
int n_common_pathkeys;
(void) pathkeys_count_contained_in(root->sort_pathkeys, pathkeys,
&n_common_pathkeys);
return n_common_pathkeys;
}
Your patch’s code:
static int
count_common_leading_pathkeys_ordered(List *keys1, List *keys2)
{
int ncommon;
(void) pathkeys_count_contained_in(keys1, keys2, &ncommon);
return ncommon;
}
They both call pathkeys_count_contained_in(), you are NOT adding an extra wrapper. So, I withdraw the “inline” comment.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-10-14 23:54:50 | Re: get rid of RM_HEAP2_ID |
Previous Message | Peter Smith | 2025-10-14 23:29:32 | Re: pg_createsubscriber - more logging to say if there are no pubs to drop |