Re: moving pg_xlog -- yeah, it's worth it!
От | Kevin Grittner |
---|---|
Тема | Re: moving pg_xlog -- yeah, it's worth it! |
Дата | |
Msg-id | 4B750193020000250002F22D@gw.wicourts.gov обсуждение исходный текст |
Ответ на | moving pg_xlog -- yeah, it's worth it! ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: moving pg_xlog -- yeah, it's worth it!
Re: moving pg_xlog -- yeah, it's worth it! |
Список | pgsql-performance |
Hannu Krosing wrote: > Can it be, that each request does at least 1 write op (update > session or log something) ? Well, the web application connects through a login which only has SELECT rights; but, in discussing a previous issue we've pretty well established that it's not unusual for a read to force a dirty buffer to write to the OS. Perhaps this is the issue here again. Nothing is logged on the database server for every request. > If you can, set > > synchronous_commit = off; > > and see if it further increases performance. I wonder if it might also pay to make the background writer even more aggressive than we have, so that SELECT-only queries don't spend so much time writing pages. Anyway, given that these are replication targets, and aren't the "database of origin" for any data of their own, I guess there's no reason not to try asynchronous commit. Thanks for the suggestion. -Kevin
В списке pgsql-performance по дате отправления: