Re: UPDATEDs slowing SELECTs in a fully cached database

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: lars <lhofhansl(at)yahoo(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Ivan Voras <ivoras(at)freebsd(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Date: 2011-07-13 00:35:54
Message-ID: CAMkU=1zr_=QgE7if3cxAv779CwU5xt4iGtn=jMHszxX8dC5ymQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 7/12/11, lars <lhofhansl(at)yahoo(dot)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?

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Mario Splivalo 2011-07-13 00:53:32 Re: Planner choosing NestedLoop, although it is slower...
Previous Message Mario Splivalo 2011-07-12 23:57:06 Re: Planner choosing NestedLoop, although it is slower...