On Thu, May 23, 2024 at 02:27:07PM +1200, David Rowley wrote: > On Thu, 23 May 2024 at 14:01, Bruce Momjian <br...@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 <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
