Re: WALWriteLock contention
От | Robert Haas |
---|---|
Тема | Re: WALWriteLock contention |
Дата | |
Msg-id | D1385D38-E1CC-4099-BD45-CF020EEED4F5@gmail.com обсуждение исходный текст |
Ответ на | Re: WALWriteLock contention (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: WALWriteLock contention
|
Список | pgsql-hackers |
On May 17, 2015, at 11:04 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Sun, May 17, 2015 at 7:45 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> <crazy-idea>I wonder if we could write WAL to two different files in
> alternation, so that we could be writing to one file which fsync-ing
> the other.</crazy-idea>
Won't the order of transactions replay during recovery can causeproblems if we do alternation while writing. I think this is one ofthe reasons WAL is written sequentially. Another thing is that duringrecovery, currently whenever we encounter mismatch in stored CRCand actual record CRC, we call it end of recovery, but with writingto 2 files simultaneously we might need to rethink that rule.
Well, yeah. That's why I said it was a crazy idea.
I think first point in your mail related to rewrite of 8K block eachtime needs more thought and may be some experimentation tocheck whether writing in lesser units based on OS page size orsector size leads to any meaningful gains. Another thing is thatif there is high write activity, then group commits should help inreducing IO for repeated writes and in the tests we can try by changingcommit_delay to see if that can help (if the tests are already tunedwith respect to commit_delay, then ignore this point).
I am under the impression that using commit_delay usefully is pretty hard but, of course, I could be wrong.
...Robert
В списке pgsql-hackers по дате отправления: