Re: First draft of PG 17 release notes

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: First draft of PG 17 release notes
Дата
Msg-id CA+TgmobF8rzu56Km=jMYO+V6D-Z5P3Kg-0ycTzMk9NGxSnCCtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: First draft of PG 17 release notes  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Question: Why Are File Descriptors Not Closed and Accounted for PostgreSQL Backends?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PG catalog