Re: UPDATEDs slowing SELECTs in a fully cached database

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "lars" <lhofhansl(at)yahoo(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>, "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Date: 2011-07-11 19:16:44
Message-ID: 4E1B05CC020000250003F1E6@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

lars <lhofhansl(at)yahoo(dot)com> wrote:

> Stopping the UPDATEs, waiting for any CHECKPOINTs to finish,
> and then running the SELECTs indeed shows a similar slowdown.
>
> Interestingly I see very heavy WAL traffic while executing the
> SELECTs. (So I was confused as to what caused the WAL traffic).

Hint bit changes aren't logged, so if it was that you would be
seeing writes to the heap, but not to the WAL. Clean-up of dead
tuples is logged -- this is probably the result of pruning dead
tuples. You could probably reduce the impact on your SELECT
statements at least a little by making autovacuum more aggressive.

At some point you could see the overhead of autovacuum having some
impact on your SELECT statements, so you may need to experiment to
find the "sweet spot" for your load.

-Kevin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2011-07-11 20:32:05 Re: Statistics and Multi-Column indexes
Previous Message lars 2011-07-11 18:33:14 Re: UPDATEDs slowing SELECTs in a fully cached database