Re: UPDATEDs slowing SELECTs in a fully cached database - Mailing list pgsql-performance

From Jeff Janes
Subject Re: UPDATEDs slowing SELECTs in a fully cached database
Date
Msg-id CAMkU=1zr_=QgE7if3cxAv779CwU5xt4iGtn=jMHszxX8dC5ymQ@mail.gmail.com
Whole thread Raw
In response to Re: UPDATEDs slowing SELECTs in a fully cached database  (lars <lhofhansl@yahoo.com>)
Responses Re: UPDATEDs slowing SELECTs in a fully cached database
List pgsql-performance
On 7/12/11, lars <lhofhansl@yahoo.com> wrote:
>
>
> The fact that a select (maybe a big analytical query we'll run) touching
> many rows will update the WAL and wait
> (apparently) for that IO to complete is making a fully cached database
> far less useful.
> I just artificially created this scenario.

I can't think of any reason that that WAL would have to be flushed
synchronously.

There is already code that makes transactions that only have certain
kinds of "maintenance" WAL to skip the flush. Could this pruning WAL
be added to that group?

pgsql-performance by date:

Previous
From: Mario Splivalo
Date:
Subject: Re: Planner choosing NestedLoop, although it is slower...
Next
From: Mario Splivalo
Date:
Subject: Re: Planner choosing NestedLoop, although it is slower...