From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: First draft of PG 17 release notes |
Date: | 2024-05-23 02:27:07 |
Message-ID: | CAApHDvpGjet1ssS7dxTXUmD1ZU6ivkgHqW2a9tGYDA3ST7GH0g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 23 May 2024 at 14:01, Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2024-05-23 03:22:09 | Re: using extended statistics to improve join estimates |
Previous Message | David Rowley | 2024-05-23 02:15:38 | Re: Speed up JSON escape processing with SIMD plus other optimisations |