Re: UPDATEDs slowing SELECTs in a fully cached database

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: lars <lhofhansl(at)yahoo(dot)com>, pgsql-performance(at)postgresql(dot)org, "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Date: 2011-07-12 16:23:36
Message-ID: CAHyXU0x4bCecWRdpRGypckHHfkZiBCv3=7rCqMswcHj3hRYMjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Jul 12, 2011 at 9:36 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> lars <lhofhansl(at)yahoo(dot)com> wrote:
>
>> I am not trying to optimize this particular use case, but rather
>> to understand what Postgres is doing, and why SELECT queries are
>> affected negatively (sometimes severely) by concurrent (or even
>> preceding) UPDATEs at all when the database resides in the cache
>> completely.
>
> I think we're stuck in terms of trying to guess what is causing the
> behavior you are seeing.  Things which would help get it "unstuck":
>
> (1)  More information about your load process.  Looking at the code,
> I could sort of see a possible path to this behavior if the load
> process involves any adjustments beyond straight INSERTs or COPYs
> in.
>
> (2)  You could poke around with a profiler, a debugger, and/or
> the contrib/pageinspect module to sort things out.

hm, also strace on the 'select' process might give some clues.

merlin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Mario Splivalo 2011-07-12 18:11:46 Planner choosing NestedLoop, although it is slower...
Previous Message Gael Le Mignot 2011-07-12 15:44:08 Re: Memory usage of auto-vacuum