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=1w5v2gT9p2P8EzzJj_uv1PaKzx3XsRRBo=b+fhSm9UUzA@mail.gmail.com
Whole thread Raw
In response to Re: UPDATEDs slowing SELECTs in a fully cached database  (lars <lhofhansl@yahoo.com>)
List pgsql-performance
On Wed, Jul 13, 2011 at 11:10 AM, lars <lhofhansl@yahoo.com> wrote:

...

> => update test set created_by = '000000000000001' where tenant =
> '000000000000001';
> UPDATE 3712
...
>
> There seems to be definitely something funky going on. Since created_by is
> indexed it shouldn't do any HOT logic.

Once the update has been run once, further executions are degenerate
(they replace the updated indexed column with the same value it
already holds).  The HOT code detects this and uses a HOT update in
this case despite the apparent update of an indexed column.


Cheers,

Jeff

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database
Next
From: Jeff Janes
Date:
Subject: Re: UPDATEDs slowing SELECTs in a fully cached database