Re: First draft of PG 17 release notes - Mailing list pgsql-hackers

From David Rowley
Subject Re: First draft of PG 17 release notes
Date
Msg-id CAApHDvpGjet1ssS7dxTXUmD1ZU6ivkgHqW2a9tGYDA3ST7GH0g@mail.gmail.com
Whole thread Raw
In response to Re: First draft of PG 17 release notes  (Bruce Momjian <bruce@momjian.us>)
Responses Re: First draft of PG 17 release notes
List pgsql-hackers
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.

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?

David



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Speed up JSON escape processing with SIMD plus other optimisations
Next
From: Andrei Lepikhov
Date:
Subject: Re: using extended statistics to improve join estimates