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.
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? |