| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | lars <lhofhansl(at)yahoo(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-14 21:45:43 |
| Message-ID: | CAMkU=1w5v2gT9p2P8EzzJj_uv1PaKzx3XsRRBo=b+fhSm9UUzA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Jul 13, 2011 at 11:10 AM, lars <lhofhansl(at)yahoo(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2011-07-14 23:03:43 | Re: UPDATEDs slowing SELECTs in a fully cached database |
| Previous Message | Tom Lane | 2011-07-14 15:47:00 | Re: UPDATEDs slowing SELECTs in a fully cached database |