Re: Draft release notes complete
От | Bruce Momjian |
---|---|
Тема | Re: Draft release notes complete |
Дата | |
Msg-id | 20120510174423.GY16881@momjian.us обсуждение исходный текст |
Ответ на | Re: Draft release notes complete (Peter Geoghegan <peter@2ndquadrant.com>) |
Ответы |
Re: Draft release notes complete
(Robert Haas <robertmhaas@gmail.com>)
Re: Draft release notes complete (Jeff Janes <jeff.janes@gmail.com>) |
Список | pgsql-hackers |
On Thu, May 10, 2012 at 01:11:54PM +0100, Peter Geoghegan wrote: > On 10 May 2012 04:11, Bruce Momjian <bruce@momjian.us> wrote: > > I have completed my draft of the 9.2 release notes, and committed it to > > git. I am waiting for our development docs to build, but after 40 > > minutes, I am still waiting: > > "Allow the bgwriter, walwriter, and statistics collector to sleep more > efficiently during periods of inactivity (Peter Geoghegan, Heikki > Linnakangas, Tom Lane)...This reduces CPU wake-ups." > > I think that there should be mention of why this is a good thing. When > fully idle the server reaches less than a single wake-up per second, I added text that says it reduces power consuption on idle servers. > which I think is a nice, relevant fact. You should add the archiver > and checkpointer to that list, though I suppose you could argue that > the checkpointer, as a "new" auxiliary process, shouldn't count. I added the archiver and checkpointer to the list. Seems there is no doc section to link to for these processes. > Why can't we call group commit group commit (and for that matter, > index-only scans index-only scans), so that people will understand > that we are now competitive with other RDBMSs in this area? "Improve > performance of WAL writes when multiple transactions commit at the > same time" seems like a pretty bad description, since it doesn't make > any reference to batching of commits. Also, I don't think that the I didn't call it "group commit" because we have settings we used to regard as group commit: #commit_delay = 0 # range 0-100000, in microseconds #commit_siblings = 5 # range 1-1000 These are still there. Should they be removed? I updated the release docs to call the item "group commit" because I now don't see any reference to that term in our docs. > placement of this as the second to last performance feature is > commensurate with its actual importance. Still, the actual major I am really unclear on how the performance items should be listed in terms of importance, so I am ready for someone to tell me the proper order. > feature list is a much more relevant indicator of how it is felt that > individual features should be weighed, and of course that hasn't been > decided upon yet. > > "Change pg_stat_statements' total_time column to be measured in > milliseconds (Tom Lane)". Surely this should be under > "pg_stat_statements"? I had it above because it was a major incompatibility. I do have some incompatibilities, e.g. pg_upgrade, that I kept in their own section. Should I move it? Can we assume people will also look in per-module sections for incompatibility information? > Does "Make the visibility map crash-safe" really belong under "Performance"? Not sure where to move that to. Source Code doesn't seem right. I moved it lower in the performance section. > It's not clear that this isn't just within comments that will be later > removed, but I'd remove all references to "we". Fixed. Attached patch applied. Thanks. I do appreciate all the feedback. I think I got almost zero feedback on 9.1 and it was kind of weird. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Вложения
В списке pgsql-hackers по дате отправления: