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

From Robert Haas
Subject Re: First draft of PG 17 release notes
Date
Msg-id CA+TgmobF8rzu56Km=jMYO+V6D-Z5P3Kg-0ycTzMk9NGxSnCCtA@mail.gmail.com
Whole thread Raw
In response to Re: First draft of PG 17 release notes  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Thu, May 23, 2024 at 11:04 PM Bruce Momjian <bruce@momjian.us> wrote:
> 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 don't get this at all. If we can't tell the difference between
O(N^2) and O(N), then N was small enough that there wasn't any real
need to optimize in the first place. I think we should be assuming
that if somebody took the trouble to write a patch, the difference did
matter. Hence the change would be user-visible, and should be
documented.

"Internal Performance" doesn't make a lot of sense to me as a section
heading. What does "Internal" mean here as opposed to "General"? I
suspect you mean to imply that the user won't be able to tell the
difference, but I doubt that very much. We make performance
improvements because they are user-visible. If a performance
improvement is so miniscule that nobody would ever notice the
difference, well then I don't think it needs to be release-noted at
all, and we might have a few changes like that where people were
mostly aiming for code cleanliness. But in general, what people do is
look for something that's slow (for them) and try to make it faster.
So the presumption should be that a performance feature has a
meaningful impact on users, and then in rare cases we may decide
otherwise.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Question: Why Are File Descriptors Not Closed and Accounted for PostgreSQL Backends?
Next
From: Tom Lane
Date:
Subject: Re: PG catalog