From: | James Hunter <james(dot)hunter(dot)pg(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] Move clause_sides_match_join() into pathnode.h |
Date: | 2024-10-10 15:25:12 |
Message-ID: | CAJVSvF5V0VKna=K3cK5jAnVw1widV1apBA7L1B+UG0YSPn2dyw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 9, 2024 at 5:26 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Thu, 10 Oct 2024 at 08:38, James Hunter <james(dot)hunter(dot)pg(at)gmail(dot)com> wrote:
> > We had two almost-identical copies of the utility function
> > clause_sides_match_join() -- one in joinpath.c, and one in
> > analyzejoins.c. Both copies were marked "inline," so we might as well
> > just move the (inline) function definition into a common header file.
> > I chose pathnode.h, because it is already #included by both of the .c
> > files.
>
> I'm in favour of the deduplication. pathnode.h seems like a strange
> choice. restrictinfo.h seems more suited.
Moved into restrictinfo.h, instead, in next revision. (The only reason
I initially chose pathnode.h is because it was already #included by
the two .c files; I agree, after glancing over restrictinfo.h, that it
seems like a better fit.)
>
> (I really wonder how much the inlining is giving us given that the
> function itself calls other non-inlineable functions)
I wondered the same! But, at least the branch can be inlined?
Thanks for looking over the patch,
James
Attachment | Content-Type | Size |
---|---|---|
0001-Move-clause_sides_match_join-into-restrictinfo.h.patch | application/octet-stream | 7.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-10-10 15:26:47 | Re: Using per-transaction memory contexts for storing decoded tuples |
Previous Message | Rohit Sivakumar | 2024-10-10 15:22:48 | Worker parallelism on EXECUTE with a non-zero fetch count |