Re: Concurrent HOT Update interference - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Concurrent HOT Update interference
Date
Msg-id 3488.1368191636@sss.pgh.pa.us
Whole thread Raw
In response to Concurrent HOT Update interference  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Concurrent HOT Update interference  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.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



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Concurrent HOT Update interference
Next
From: Merlin Moncure
Date:
Subject: Re: Concurrent HOT Update interference