Re: Concurrent HOT Update interference

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Concurrent HOT Update interference
Date: 2013-05-10 13:13:56
Message-ID: 3488.1368191636@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> So what we have is that multiple UPDATEs repeatedly accessing the same
> block will prevent each other from successful cleanup, since while one
> session is performing the update, the second session is pinning the
> block with an indexscan.

> This effect has been noted for some time during pgbench runs, where
> running with more sessions than scale factors causes contention. We've
> never done anything about it because that's been seen as a poorly
> executed test, whereas it does actually match the real situation we
> experience at "hot spots" in the table.

Uh, no. pgbench's problem at high scale factors is that multiple
sessions want to update *the same row*, not just different rows on the
same page. That contention is unavoidable.

You may in fact have a good point, but you can't prove it by reference
to pgbench.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2013-05-10 13:28:24 Re: Concurrent HOT Update interference
Previous Message Mark Kirkwood 2013-05-10 12:51:20 Re: In progress INSERT wrecks plans on table