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

From Greg Stark
Subject Re: Concurrent HOT Update interference
Date
Msg-id CAM-w4HNY8XS+yeTB-AKfvJR8tthCemmNcfd-z4hZfqzt16hB8w@mail.gmail.com
Whole thread Raw
In response to Re: Concurrent HOT Update interference  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Concurrent HOT Update interference  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Fri, May 10, 2013 at 3:04 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> a) Updating two separate rows that happen to be on the same block will
> eventually cause one or both of the rows to migrate to separate blocks
> because of 1) the inability to clean the existing block and 2) the way
> our fsm algorithm gives you a clean new block away from other people.
> That leads to a one-block-per-row situation, or in other words quite
> bad bloating, which seems to be avoidable, hence this thread.

This seems like a good behaviour to me. If you have N busy rows then
having each row in its own block minimizes contention and minimizes
the frequency of cleanups. You can't be both worried about bloating
*and* contention -- either you have relatively few busy rows per
processor in which case the bloat is minor and the contention is an
issue or you have many rows in which case the contention can't be an
issue and the bloat becomes important.


-- 
greg



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Concurrent HOT Update interference
Next
From: Christopher Browne
Date:
Subject: Re: [PATCH] Make "psql -1 < file.sql" work as with "-f"