From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | Zhihong Yu <zyu(at)yugabyte(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: fixing typo in comment for restriction_is_or_clause |
Date: | 2022-10-25 07:52:30 |
Message-ID: | CAMbWs4_-gVLN1YnheXgns8L+zPTfWW3Y_+k6Kvqtt9cuyYh+Kw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 25, 2022 at 2:25 PM John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
wrote:
>
> On Tue, Oct 25, 2022 at 9:48 AM Richard Guo <guofenglinux(at)gmail(dot)com>
> wrote:
> >
> >
> > On Tue, Oct 25, 2022 at 10:05 AM John Naylor <
> john(dot)naylor(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2022-10-25 07:56:33 | Re: fixing typo in comment for restriction_is_or_clause |
Previous Message | Alvaro Herrera | 2022-10-25 07:37:12 | Re: fixing typo in comment for restriction_is_or_clause |