Re: XLogFlush invoked about twice as many times after 9.2 group commit enhancement
От | Amit Langote |
---|---|
Тема | Re: XLogFlush invoked about twice as many times after 9.2 group commit enhancement |
Дата | |
Msg-id | CA+HiwqGSXYyXRx7mrkAOY5zx4L2tN=+wEwfHXoz7ffdc495aVA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: XLogFlush invoked about twice as many times after 9.2 group commit enhancement (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: XLogFlush invoked about twice as many times after 9.2
group commit enhancement
|
Список | pgsql-hackers |
> Why is that surprising? Most of those XLogFlush() calls will recheck > the flushed-up-to point, and realize that another backend assumed the > role of group commit leader, and flushed their WAL for them, so aside > from the wait, the call to XLogFlush is cheap for that individual > backend. It's being invoked twice as many times because backends *can* > invoke it twice as many times. After going through it again, I think, I am getting convinced it is not surprising. Since, backends are now able to return quickly from XLogFlush(), on an average, they should also be able to proceed to next transactions faster and hence cause XLogFlush() to be invoked more often. So, any rise in number of XLogFlush() calls should roughly be accounted for by increased throughput. Am I right in interpreting it this way? -- Amit Langote
В списке pgsql-hackers по дате отправления: