Kevin Grittner wrote:
> 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.
I don't think it explains it, because dirty buffers are obviously
written to the data area, not pg_xlog.
> 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.
That's worth trying.
> 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.
Yeah; since the transactions only ever write commit records to WAL, it
wouldn't matter a bit that they are lost on crash. And you should see
an improvement, because they wouldn't have to flush at all.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
