On Thu, May 10, 2012 at 10:44 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Thu, May 10, 2012 at 01:11:54PM +0100, Peter Geoghegan wrote:
>
>> 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:
My understanding of that patch is that is does not cause "group
commit" to happen, but rather when a group commit does happen
"naturally" it causes all members of the group to awaken more
quickly/efficiently than they previously would have.
>
> #commit_delay = 0 # range 0-100000, in microseconds
> #commit_siblings = 5 # range 1-1000
>
> These are still there. Should they be removed?
The new locking around releasing group commit waiters has, if
anything, made these two more effective than before. But that isn't
really saying much. It seems like these knobs are (and were)
primarily useful for doing "stupid benchmark tricks" of little
practical value. If there is an argument for removing them, I think
it would revolve around either "They never really should have been
there anyway", or "These days when people need far more commits per
second than they have revolutions per second, they buy BBU or NVRAM".
> 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.
I don't think I'd mention WAL writing at all, and just say that it
improves the concurrency of locking around group commits.
Cheers,
Jeff