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

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: aidan(at)highrise(dot)ca, jesper(at)krogh(dot)cc, hannu(at)krosing(dot)net, pgsql-performance(at)postgresql(dot)org
Subject: Re: moving pg_xlog -- yeah, it's worth it!
Date: 2010-02-12 20:11:06
Message-ID: 20100212201106.GH3737@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Kevin Grittner wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:

> > Actually, a transaction that performed no writes doesn't get a
> > commit WAL record written, so it shouldn't make any difference at
> > all.
>
> Well, concurrent to the web application is the replication. Would
> asynchronous commit of that potentially alter the pattern of writes
> such that it had less impact on the reads?

Well, certainly async commit would completely change the pattern of
writes: it would give the controller an opportunity to reorder them
according to some scheduler. Otherwise they are strictly serialized.

> I'm thinking, again, of
> why the placement of the pg_xlog on a separate file system made such
> a dramatic difference to the read-only response time -- might it
> make less difference if the replication was using asynchronous
> commit?

Yeah, I think it would have been less notorious, but this is all
theoretical.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message lionel duboeuf 2010-02-12 20:32:30 Re: Almost infinite query -> Different Query Plan when changing where clause value
Previous Message Tom Lane 2010-02-12 20:07:34 Re: 512, 600ms query becomes 7500ms... but why? Postgres 8.3 query planner quirk?