Re: moving pg_xlog -- yeah, it's worth it!

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <hannu(at)krosing(dot)net>
Cc: <alvherre(at)commandprompt(dot)com>,<aidan(at)highrise(dot)ca>, <jesper(at)krogh(dot)cc>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: moving pg_xlog -- yeah, it's worth it!
Date: 2010-02-12 13:21:55
Message-ID: 4B750193020000250002F22D@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Yeb Havinga 2010-02-12 13:31:22 Re: Immutable table functions
Previous Message Luiz Angelo Daros de Luca 2010-02-12 12:54:58 Immutable table functions