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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Draft release notes complete
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: PL/Python result set slicing broken in Python 3