On Thu, May 23, 2024 at 02:27:07PM +1200, David Rowley wrote:
> On Thu, 23 May 2024 at 14:01, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > On Thu, May 23, 2024 at 01:34:10PM +1200, David Rowley wrote:
> > > What is the best way to communicate this stuff so it's easily
> > > identifiable when you parse the commit messages?
> >
> > This is why I think we need an "Internal Performance" section where we
> > can be clear about simple scaling improvements that might have no
> > user-visible explanation. I would suggest putting it after our "Source
> > code" section.
>
> hmm, but that does not really answer my question. There's still a
> communication barrier if you're parsing the commit messages are
> committers don't clearly state some performance improvement numbers
> for the reason I stated.
For a case where O(N^2) become O(N), we might not even know the
performance change since it is a micro-optimization. That is why I
suggested we call it "Internal Performance".
> I also don't agree these should be left to "Source code" section. I
> feel that section is best suited for extension authors who might care
> about some internal API change. I'm talking of stuff that makes some
> user queries possibly N times (!) faster. Surely "Source Code" isn't
> the place to talk about that?
I said a new section "after our 'Source code' section," not in the
source code section.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.