Re: Terrible Write Performance of a Stored Procedure

Поиск
Список
Период
Сортировка
От Scott Mead
Тема Re: Terrible Write Performance of a Stored Procedure
Дата
Msg-id d3ab2ec80906290554j564dcdew7f992407df34882e@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Terrible Write Performance of a Stored Procedure  (Greg Smith <gsmith@gregsmith.com>)
Список pgsql-performance
 

You're right that it should be removed, but this explanation is wrong. The behavior as configured is actually "if there are >=100 other transactions in progress, wait 0.1 second before committing after the first one gets committed", in hopes that one of the other 100 might also join along in the disk write.

  Thanks for the correction.  My question is how you're getting .1 seconds from his commit_delay?

if (CommitDelay > 0 && enableFsync &&
    CountActiveBackends() >= CommitSiblings)
         pg_usleep(CommitDelay);

  Wouldn't this actually be 1 second based on a commit_delay of 100000?

 


Since in this case max_connections it set to 100, it's actually impossible for the commit_delay/commit_siblings behavior to trigger give this configuration.  That's one reason it should be removed.  The other is that i general, if you don't exactly what you're doing, you shouldn't be touching either parameters; they don't do what people expect them to and it's extremely unlikely you'll encounter any of the rare use cases where they might help.

   After looking, I agree, thanks again for the correction Greg. 

--Scott

    

В списке pgsql-performance по дате отправления:

Предыдущее
От: Alan McKay
Дата:
Сообщение: Re: what server stats to track / monitor ?
Следующее
От: Sean Ma
Дата:
Сообщение: random slow query