Re: fixing typo in comment for restriction_is_or_clause
От | Richard Guo |
---|---|
Тема | Re: fixing typo in comment for restriction_is_or_clause |
Дата | |
Msg-id | CAMbWs4_-gVLN1YnheXgns8L+zPTfWW3Y_+k6Kvqtt9cuyYh+Kw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fixing typo in comment for restriction_is_or_clause (John Naylor <john.naylor@enterprisedb.com>) |
Список | pgsql-hackers |
On Tue, Oct 25, 2022 at 2:25 PM John Naylor <john.naylor@enterprisedb.com> wrote:
On Tue, Oct 25, 2022 at 9:48 AM Richard Guo <guofenglinux@gmail.com> wrote:
>
>
> On Tue, Oct 25, 2022 at 10:05 AM John Naylor <john.naylor@enterprisedb.com> wrote:
>>
>> It's perfectly clear and simple now, even if it doesn't win at "code golf".
>
>
> Agree with your point. Do you think we can further make the one-line
> function a macro or an inline function in the .h file? I think this
> function is called quite frequently during planning, so maybe doing that
> would bring a little bit of efficiency.
My point was misunderstood, which is: I don't think we need to do anything at all here if the goal was purely about aesthetics.If the goal has now changed to efficiency, I have no opinion about that yet since no evidence has been presented.
Now I think I've got your point. Sorry for the misread.
Your concern makes sense. When talking about efficiency we'd better
attach some concrete proof, such as benchmark tests.
Thanks
Richard
Your concern makes sense. When talking about efficiency we'd better
attach some concrete proof, such as benchmark tests.
Thanks
Richard
В списке pgsql-hackers по дате отправления: